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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 



Introduction 

The contents of the present document are the result of contributions and discussions in Working Group 3. 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CMS Cryptographic Message Syntax 

DES Data Encryption Standard 

DSA Digital Signature Algorithm 

DTD Document Type Definition 

HTML Hypertext Markup Language 

HTTP Hypertext Transfer Protocol 

IETF Internet Engineering Task Force 

IP Internet Protocol 

IPSEC Internet Protocol Security 

MD5 Message Digest 5 

MIME Multipurpose Internet Mail Extensions 

OSP Open Settlement Protocol 

PIN Personal Identification Number (e.g. for automated teller machines) 

PKCS Public Key Cryptography Standard 
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RAS Registration Admission and Status 

RSA Rivest Shamir Adleman 

SHA Secure Hash Algorithm 

S/MIME Secure Muhipurpose Internet Mail Extensions 

SSL Secure Socket Layer 

TCP Transmission Control Protocol 

TLS Transport Layer Security 

URL Uniform Resource Locator 

UTC Universal Time Co-ordinated 

UTF Universal Text Format 

XML Extensible Markup Language 



4 Open Settlement Protocol Architecture 

This clause introduces the protocol architecture for the OSP specification. It identifies the major protocols used by 
communicating parties, and it outlines their relationship to each other. The clause also describes the overall format of 
messages exchanged by the protocols. The intent of this clause is to outline the framework for the standard's protocols 
and message formats; later clauses detail specific profiles for these protocols and the specific message content. 



4.1 



Communication Protocols 



As figure 1 shows, systems conforming to the OSP specification use a combination of the Hypertext Transfer Protocol 
(HTTP), and either the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to transfer pricing, authorization, 
and usage information. As the figure indicates, these protocols are layered on top of the Transmission Control Protocol 
(TCP) for communication across Internet Protocol (IP) networks. 



OSP 



XML (presentation) 



HTTPvl .0 



SSLv3 



TCP port 443 



TCP port 80 



IP 



Figure 1 : Open Settlement Protocol Architecture for Pricing, 
Authorization, and Usage Exchange 

4.1 .1 Secure Sockets Layer/Transport Layer Security 

The Secure Sockets Layer and Transport Layer Security protocols add authentication and privacy to TCP connections. 
SSL is the standard protocol for securing web browsing. As such, it is widely deployed on the Internet and is 
distinguished by considerable operational experience. SSL also enjoys near universal support from firewalls and proxy 
servers. TLS is an updated version of SSL currently being developed within the Internet Engineering Task Force 
(IETF). TLS is heavily based on SSL and, although it is not strictly backwards compatible with SSL, systems 
supporting both TLS and SSL can automatically recognize either protocol and adapt as required to ensure 
interoperability. 

NOTE: As other industry standard mechanisms for IP-based security (for example, IPSEC) reach maturity, later 
revisions to the present document may incorporate support for those mechanisms in addition to SSL/TLS. 
Such revisions to the security mechanisms may also permit the use of an unreliable transport such as 
UDP. 

4.1 .2 Hypertext Transfer Protocol 

The Hypertext Transfer Protocol (HTTP) is the standard protocol for web-based communications. HTTP has been 
adopted for a wide variety of purposes including proxy services, bi-directional content delivery, database access, 
network management, and metering information. HTTP is by far the most widely used application protocol on the 
Internet, and is supported by all significant firewalls and proxy servers. 
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4.2 Message Format 



To illustrate the overall format of OSP messages, figure 2 shows an example message. As the figure indicates, the 
content within the HTTP message is formatted according to the standard for Multipurpose Internet Mail Extensions 
(MIME). The individual components of the message are a document conforming to the Extensible Markup Language 
(XML) specification and a Secure MIME (S/MIME) digital signature. 

NOTE: The digital signature is optional and, if omitted, the message content consists solely of a XML document. 



HTTP Header 



Message Content 




Digital Signature 



POST scripts/settlements HTTP/1.0 
content-type: multipart/signed; 

pr ot ocol= "appli cat ion /pkcs 7 -signature" 

micalg=shal ; 

boundary=bar 
content-length: 844 

— bar 

Content-Type: text/plain 

Content-Length: 524 

<?xml version= ' 1 . ' ?> 

<Message messageld="123454321" random="123456 
<AuthorizationRequest component I d=" 987 65 6 
<Timestamp> 

1998-04-24T17:03:00Z 
</Timestamp> 
<CallId> 

1234432198766789 
</CallId> 
<SourceInfo type="el64 

81458811202 
</SourceInfo> 
<DestinationInf o type= 

4766841360 
</DestinationInfo> 
<Service/> 
<MaximumDestinations> 

5 
</MaximumDestinations> 
</AuthorizationRequest> 
</Message> 

— bar 

Content-Type : application/pkcs7-signature 

Content-Length: 191 

GhyHhHUujhJhjH77n8HHGTrfvbnj75 6tbB9HG4VQpfyF4 67GhIG 
fHfYT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
bB9HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfH 
fYT6ghyHhHUujpfyF47GhIGfHfYT64VQbnj75 6 

— bar — 




Figure 2: Example Message Showing Overall Format 

4.2.1 Multipurpose Internet Mail Extensions 

All messages exchanged as part of this OSP specification conform to the Multipurpose Internet Mail Extensions 
(MIME) specification. The MIME specification defines mechanisms to combine individual components of arbitrary 
format (e.g. text, graphics, audio information, binary data, etc.) into a single message. Originally designed for electronic 
mail, the MIME specification has been adapted for a variety of communication applications, including web browsing. 
MIME format is widely supported by existing firewalls and proxy servers. 

4.2.2 Extensible Markup Language 

The first part of each MIME message is a document conforming to the Extensible Markup Language (XML) standard. 
As an extension of the widely deployed Hypertext Markup Language (HTML), XML can be readily parsed by firewalls 
and proxy servers. Unlike HTML, though, XML is readily extensible and can easily support rich, structured data such 
as pricing and usage information. 
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4.2.3 Secure MIME 

The second part of each MIME message, if present, is a digital signature conforming to the Secure Multipurpose 
Internet Mail Extensions (S/MIME). S/MIME format includes support for multiple digest and signing algorithms and 
for variable cryptographic strength (e.g. key lengths). S/MIME format is also self-identifying with respect to these 
parameters, so that a recipient can derive the necessary information for verifying the signature from the signature data. 

NOTE: This does not imply that the recipient is guaranteed to be able to verify the signature, only that the 
recipient can tell what it needs to perform the verification. (So that, for example, the recipient may 
identify a signing algorithm that it does not support). 



5 Protocol Profiles 

This clause specifies the profiles for the protocols required by this OSP specification. It identifies the normative 
references to those protocols, as well as the specific versions, options, and extensions that the present document 
requires. The specific protocols described in this clause are the Secure Sockets Layer (SSL) and Transport Layer (TLS) 
protocols and the Hypertext Transfer Protocol (HTTP). The clause concludes by specifying the overall format of the 
messages conveyed through these protocols. The following clauses describe the message content in detail. 

5.1 Secure Sockets Layer/Transport Layer Security 

If secure authentication of the server is desired, or if confidentiality of the information exchanged between client and 
server is desired, the communication between the devices shall be secured using the Secure Sockets Layer (SSL) or 
Transport Layer Security (TLS) as described in this clause. 

5.1.1 Protocol Version 

Conforming systems shall support version 3.0 of the Secure Sockets Layer protocol [6] to secure their communications. 

NOTE: As an implementation option, systems may support version 1 .0 of the Transport Layer Security protocol 
[24] or later versions. 

5.1.2 Client/Server Roles 

When initiating a communication as part of the present document, the initiating system shall act as an SSL/TLS client 
while the responding system shall act as an SSL/TLS server. 

5.1.3 CipherSuites 

Annex B documents the cryptographic algorithms required and recommended by the present document, including 
SSL/TLS ciphersuites. 

5.2 Hypertext Transfer Protocol 

5.2.1 Protocol Version 

Conforming systems shall support version 1 .0 of the Hypertext Transfer Protocol [2] as the base transfer protocol for 
their messages. 

NOTE: As an implementation option, systems may support HTTP version 1.1 [4]. 

5.2.2 Client/Server Roles 

When initiating a communication as part of the present document, the initiating system shall act as an HTTP client, 
while the responding system shall act as an HTTP server. 
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5.2.3 TCP Port 

Clients shall support sending their requests to TCP port 443 if SSL/TLS is being used, and to TCP port 80 otherwise. As 
an implementation option, communicating parties may agree to communicate via other TCP ports. 

5.2.4 HTTP Methods 

Requests from clients to a server shall be in the form of HTTP request messages using the POST method. Responses 
from a server shall consist of valid HTTP response messages. 

5.2.5 Uniform Resource Identifier 

The uniform resource identifier included in the POST request is not specified in the present document, but rather is 
subject to prior agreement between the communicating parties. 

5.2.6 HTTP Headers 

The HTTP header of the POST method shall minimally consist of the request-line. All request-header and 
general-header fields are optional. If present, they shall conform to the HTTP standard [2]. The status-line for the HTTP 
responses shall be present in those responses, and it shall conform to the HTTP standard, including status-code and 
reason-phrase values. All response-header and general-header fields are optional. If present, they shall conform to the 
HTTP standard. 



5.2.7 HTTP Entity Body 



Each message (i.e. HTTP entity body) conveyed as part of the present document shall conform to the Multipurpose 
Internet Mail Extensions standard [5], and shall, if signed, consist of exactly two parts, an Extensible Markup Language 
document and a Secure Multipurpose Internet Mail Extensions digital signature, as specified in the following two 
clauses. The highest level structure for each message shall conform to the multipart/signed syntax defined in 
S/MIME [18]. The message's media type shall be "multipart/signed" with appropriate parameters (e.g. protocol of 
"application/pkcs7-signature" and micalg of "shal.") The entity shall indicate the correct content-length value, as 
defined in the HTTP standard [2] . 

If not signed, each message shall simply consist of a single, text/plain part. 



6 XML Content 

This clause specifies the actual message format used by the OSP to exchange pricing, authentication and authorization, 
and usage information. It outlines the overall XML document structure, lists the individual XML elements, and 
describes how those elements are combined into exchanges. 

6.1 Document Structure 

6.1 .1 Multipurpose Internet Mail Extensions Conformance 

As the first part of a Multipurpose Internet Mail Extensions (MIME) message, each message content shall conform to 
the MIME standard [5] as indicated below. 

6.1.1.1 Content-Type 

The message's content-type shall be designated text/plain. 

NOTE: It is anticipated that the Internet Engineering Task Force (IETF) will eventually define a MIME 
content-type for XML documents (e.g. text/xml). When such a definition is available, subsequent 
revisions of the present document may specify the use of that content-type instead of text/plain. 
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6.1.1.2 Content-Length 

All messages shall indicate the correct content-length value as defined in the MIME standard. 

6.1.1.3 Transfer Encoding 

As XML documents can be carried within the HTTP protocol in their native format, no transfer encoding 
(e.g. quoted-printable or base-64) shall be used. 

NOTE: Since XML content is carried in its native encoding, that encoding will not conform to the 

recommendations for the text/plain content-type. In particular, the XML encoding specifies the use of a 
single line-feed character (#xA) to indicate line ending rather than the return/line-feed pair. Although not 
the default encoding for text/plain, such an encoding does not violate the MIME standard. 

6.1.2 XML Conformance 

The actual message content itself shall conform to the XML standard [3]. As part of that conformance, systems shall 
follow the well-formedness and character encoding requirements as follows. 

6.1.2.1 XML Version 

Message content shall conform to version 1 .0 of the XML standard, and shall indicate that version with the required 
XML prologue of <?xml version= ^1 . 0' ?>. 

6.1.2.2 Well-Formed Constraint 

All messages shall be well-formed XML documents, as defined in the [3] standard. Messages may be valid XML 
documents as well, by referencing the appropriate XML document type definitions (DTDs). Strict validity (as defined 
by [3]) is not required, however. 

NOTE: The terms "well-formed" and "valid" have specific meanings with the XML standard, and are used to 
indicate specific degrees of conformance to the standard. 

6.1.2.3 Character Encoding 

Messages may use any character set permitted by the XML standard. As specified in that standard, however, all 
implementations shall be capable of generating and interpreting UTF-8 and UTF-16 encodings. In the absence of 
explicit knowledge that the receiving system can support other character encodings, sends shall use UTF-8 or UTF-16 
encoding [23]. 
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6.1.3 XML Framework 

All messages shall conform to the overall framework illustrated in figure 3. As the figure shows, messages consist of a 
single root entity, which contains one or more components, each of which consists in turn of one or more elements. 
These elements may include XML attributes. 



<message> 



<component> 



<component> 



<element> 



<element> 



<element> 



<element> 



=:element> 



<element> 



Figure 3: Overall XML Framework 



6.1.3.1 



Root Entity 



<!DOCTYPE Message [ 

<!ELEMENT Message ( ( Pricinglndication | PricingConf irmation | AuthorizationRequest 

AuthorizationResponse I Authorizationlndication | AuthorizationConf irmation | Usagelndication 

UsageConf irmation | ReauthorizationRequest I ReauthorizationResponse 

SubscriberAuthenticationRequest I SubscriberAuthenticationResponse I Capabilitieslndication 

CapabilitiesConf irmation )+ )> 
<!ATTLIST Message messageld ID #REQUIRED 
random CDATA #REQUIRED> 

]> 

The root entity for each message shall be a Message element. It shall contain the components documented above, as 
well as a unique identifier attribute and a random attribute. 



6.1.3.2 



Random Attribute 



Each Message element shall include a random attribute. This attribute's value shall be a random number, encoded as a 
decimal character string. The attribute ensures that each message contains some random content, and it therefore 
increases the security of the S/MIME digital signature. 

NOTE: Systems should use a cryptographically strong random number generator as the source for this attribute's 
value. Standard library random number functions (such as from the ANSI C standard) are generally not 
cryptographically strong, and should not be used. 



6.1.3.3 



Identifier Attribute 



Each message and each component within a message shall include a unique identifier for that element. The system that 
initiates communication (through either a request or an indication) shall ensure that the identifier is unique. The system 
that replies (through either a response or a confirmation) shall use the identifier value to associate messages and 
components in its response or confirmation with the corresponding elements in the request or indication. The identifier 
attribute consists of an arbitrary character string, and is indicated by the attribute names messageld or 
component Id, as appropriate. 
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6.1.3.4 Critical Attribute 

All XML elements shall include a special attribute with the name critical that takes values of "true" or 
"false". This attribute indicates whether or not processing of the message can safely proceed if the particular element 
is not supported by the receiver. 

If a system receives a component containing a critical element that it does not support, that system shall not accept or 
process the component. 

If the critical attribute is omitted from an element (and its parents), that element shall be treated as if the critical 
attribute was present with the value "true ". 

The value of the critical attribute (whether explicit or implied) for an element shall apply to all sub-elements of the 
element unless a sub-element explicitly indicates otherwise. 

6.1.3.5 Extensions 

Organizations may define additional elements or components beyond those documented in the present document. To 
ensure that no two organizations use the same named element, all private extensions shall have, as a prefix to their 
name, an officially registered Internet domain name belonging to the defining party. That domain name may be 
separated from the element name by a colon. If, for example, the organization that owns the Internet domain name 
acme.com wishes to add an element named PrivateOption, the tags delineating that element will be 
<acine . com: PrivateOption> and </acine . com: PrivateOption>. As noted above, the critical 
attribute may be used to indicate to a recipient whether or not it can safely ignore a private extension that it does not 
understand or support. 



6.2 Components 



Components are the main elements within the each message. The <Message> element shall contain at least one and 
may contain more than one component. The components defined in this revision of the standard include pairs to effect 
pricing exchange (Pricinglndication and PricingConf irmation), obtain authorization 
(AuthorizationRequest and AuthorizationResponse), verify authorization 
(Authorizationlndication and AuthorizationConf irmation), refresh authorization 
(ReauthorizationRequest and ReauthorizationResponse), report usage (Usagelndication and 
UsageConf irmation), authentication subscribers (SubscriberAuthenticationRequest and 
SubscriberAuthenticationResponse) and exchange capabilities (Capabilitieslndication and 
Capabi 1 it iesConf irmation). 



6.2.1 Pricinglndication 



<!ELEMENT Pricinglndication ( Timestamp, Sourcelnfo, Destinationinf o. Currency, Amount, Increment, 

Unit, Service, ValidAfter, ValidUntil )> 
<!ATTLIST Pricinglndication componentid ID #REQUIRED> 

A Pricinglndication component identifies the price for a particular service. It is composed of several elements, 
as indicated above. 

For example, the following XML content states that the cost of basic telephone calls from the United States (country 
code 1) to France (country code 33) is US$ 0,50 per minute, effective immediately and indefinitely. 

<PricingIndication component I d=" 1234 5 57 8 90 "> 
<Timestamp> 

1997-05-02T19:03:00Z 
</Timestamp> 
<SourceInfo tYpe="el64pref ix"> 
1 
</SourceInfo> 
<DestinationInfo type="el 54prefix"> 
33 
</DestinationInf o> 
<Currency> 
USD 
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</CurrencY> 
<Amount> 
0.5 
</Amount> 
<Increment> 
60 
</Increment> 
<Unit> 
s 
</Unit> 
<Service/> 

<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 

6.2.2 PricingConfirmation 

<!ELEMENT PricingConfirmation ( Timestamp, Status )> 
<!ATTLIST PricingConfirmation componentid ID #REQUIRED> 

A PricingConfirmation component indicates acceptance or rejection of the corresponding 
Pricinglndication. The componentid attribute associates the confirmation with the indication. The only 
elements within the PricingConfirmation are the Timestamp and Status elements. 

6.2.3 AuthorizationRequest 

<!ELEMENT AuthorizationRequest ( Timestamp, Callld+, Sourcelnfo, SourceAlternate*, 
Destinationinf o, DestinationAlternate*, Service, MaximumDestinations, Token*, 
SubscriberAuthenticationInf o* ) > 

<!ATTLIST AuthorizationRequest componentid ID #REQUIRED> 

An AuthorizationRequest asks for authorization to use resources. In the context of basic Internet telephony 
service, it asks for authorization to complete a phone call. The call, for example, may be identified by ITU-T 
Recommendation E.164 [12] numbers in the Sourcelnfo and Destinationinf o elements. The requesting 
system may leave the choice of peer endpoints up to the authorizing server, or it may specify the peer endpoint itself in 
a DestinationAlternate element. 

The client shall provide one or more Callld elements in the request. A single Callld element implies that the client 
wishes to use that call identifier for all possible destinations returned in the AuthorizationResponse. Multiple 
Callld elements imply that the client wishes each potential destination to have its own call identifier. If the client 
wishes to specify multiple call identifiers, the number of Callld elements shall be equal to the value of the 
MaximumDestinations element. 

The AuthorizationRequest message may request either authorization information, call routing information, or 
both. When requesting authorization information only, clients shall specify a MaximumDestinations value of zero 
(0). When requesting call routing information only, clients may omit any SourceAlternate elements that identify a 
subscriber, and they may include a Token received as the result of a prior authorization. In addition, clients may 
include previously received SubscriberAuthenticationInf o elements. 

NOTE 1: The use of the AuthorizationRequest message is not intended to be a replacement for, or 

supersede any ITU-T Recommendation H.323 [13] Registration Admission and Status (RAS) messages. 
Although the elements of the AuthorizationRequest are similar to information elements in RAS 
messages, AuthorizationRequest is intended for use in the bulk transfer of authorization tokens or 
other scenarios in which RAS signalling would not be appropriate. 

NOTE 2: The present document permits either party in an authorization exchange to determine the call routing 

information (e.g. identifying the peer endpoint for the call). If the client wishes to explicitly specify call 
routing, it does so by including one or more DestinationAlternate elements (e.g. of type 
"transport" containing the IP address and port number of the peer endpoint) in the 
AuthorizationRequest. If the server is performing call routing, it returns the information in the 
AuthorizationResponse. The DestinationAlternate elements are advisory during the 
request. The server should attempt to use one of the endpoints specified, but it is free to substitute a 
different set of endpoints if it is unable to settle the call using those specified. 
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If no routing is required, this shall be explicitly indicated by setting MaximumDestinations to "0". 



6.2.4 AuthorizationResponse 



<!ELEMENT AuthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination* )> 
<!ATTLIST AuthorizationResponse componentid ID #REQUIRED> 

An AuthorizationResponse component returns authorization information corresponding to an 
AuthorizationRequest. It includes a Timestamp, a Status element, a Transactionid, optional tokens, 
and zero or more Destination elements. Any tokens present are assumed to apply to all destinations. The response 
includes a componentid attribute to associate it with the appropriate AuthorizationRequest. 

NOTE: If a client has expressed its own call routing preferences in the AuthorizationResponse (e.g. with 
DestinationAlternate elements of type transport), then the server should make every attempt 
to honour those preferences by returning appropriate Destination elements. The server may also 
include alternative destinations in its response. 

6.2.5 Authorizationlndication 

<!ELEMENT Authorizationlndication ( Timestamp, Role, Callld, Sourcelnfo, SourceAlternate*, 

Destinationinf o, DestinationAlternate*, Service, Token* )> 
<!ATTLIST Authorizationlndication componentid ID #REQOIRED> 

An Authorizationlndication asks for verification of previously issued authorization, typically by asking for 
verification of an authorization token. Because tokens may be opaque to the terminating endpoint, that endpoint may 
not be able to determine the originator of a particular token. It is therefore acceptable to pass an entire sequence of 
tokens from a setup message in this component, and it is acceptable to send simultaneous 
Authorizationlndication messages to multiple servers. The server shall be capable of recognizing 
authorization tokens in addition to validating them. 

NOTE: Even though the present document defines messages for validating authorization tokens, it does not 

require their use. In particular, some tokens may be constructed so that they can be completely verified in 
the peer system (e.g. through the use of digital signatures). 

6.2.6 AuthorizationConfirmation 

<!ELEMENT AuthorizationConfirmation ( Timestamp, Status, ValidAfter, ValidUntil )> 
<!ATTLIST AuthorizationConfirmation componentid ID #REQUIRED> 

An AuthorizationConfirmation component indicates whether or not an authorization is valid. It includes a 
Timestamp, a Status element and validation time limits. The confirmation also includes a componentid attribute 
to associate it with the appropriate Authorizationlndication. 



6.2.7 Usagelndication 



<!ELEMENT Usagelndication ( Timestamp, Role, Transactionid, Callld, Sourcelnfo, SourceAlternate*, 

Destinationinf o, DestinationAlternate*, UsageDetail*) > 
<!ATTLIST Usagelndication componentid ID #REQUIRED> 

The Usagelndication component reports resource usage. In the context of basic Internet telephony service, this is 
typically call duration. 

6.2.8 UsageConfirmation 

<! ELEMENT UsageConfirmation ( Timestamp, Status )> 
<!ATTLIST UsageConfirmation componentid ID #REQUIRED> 

A UsageConfirmation component indicates acceptance or rejection of the corresponding Usagelndication. 
The componentid attribute associates the confirmation with the indication. The only elements within the 
UsageConfirmation are the Timestamp and Status elements. 
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6.2.9 ReauthorizationRequest 



<!ELEMENT ReauthorizationRequest ( Timestamp, Role, Callld, Sourcelnfo?, SourceAlternate*, 

Destinationinf o?, DestinationAlternate*, Transactionid, UsageDetail*, Token* )> 
<!ATTLIST ReauthorizationRequest componentid ID #REQUIRED> 

A ReauthorizationRequest component requests a reauthorization of a previously authorized service. A client 
may use this message, for example, if a previous authorization has expired. 



6.2.10 ReauthorizationResponse 



<!ELEMENT ReauthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination* )> 
<!ATTLIST ReauthorizationResponse componentid ID #REQUIRED> 

A ReauthorizationResponse component indicates acceptance or rejection of the corresponding 
ReauthorizationRequest. Any tokens present are assumed to apply to all destinations. The componentid 
attribute associates the response with the request. 

6.2.1 1 SubscriberAuthenticationRequest 

<!ELEMENT SubscriberAuthent icat ionRequest (Timestamp, Sourcelnfo, SourceAlternate*, 

Destinationinf o?. Service?) > 
<!ATTLIST SubscriberAuthenticationRequest componentid ID #REQUIRED> 

A SubscriberAuthenticationRequest asks for authentication of a subscriber's credentials, typically in the form of a 
ISO/IEC 7812-1 [30] identification card number and associated personal identification number. 

6.2.12 SubscriberAuthenticationResponse 

<!ELEMENT SubscriberAuthent icat ionResponse (Timestamp, Status, SubscriberAuthenticationInf o*) > 
<!ATTLIST SubscriberAuthenticationResponse componentid ID #REQUIRED> 

A SubscriberAuthenticationResponse component returns an indication of whether the subscriber's credentials are 
considered authentic. 



6.2.13 Capabilitieslndication 



<!ELEMENT Capabilitieslndication (Deviceinf o*, OSPVersion, OSPCapability*, Resources?) > 
<!ATTLIST Capabilitieslndication componentid ID #REQUIRED 

critical ( true I false ) #FIXED "false"> 

To identify the OSP features it should use with a particular server, a client sends that server a 

Capabilitieslndication message. That message indicates the highest version of OSP that the client is willing 
to support, as well as the specific capabilities it wishes to use. The server responds with a 

CapabilitiesConf irmation message. This message indicates the version of OSP that the two parties should use 
for their communication, and it provides the client details about how to use the services it requires. 

If the server responds to a Capabilitieslndication message with anything other than a 
CapabilitiesConf irmation message (e.g. an error status), the client should assume that the server is only 
capable of support for version 1.4.3 of the specification. 
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6.2.14 CapabilitiesConfirmation 



<!ELEMENT CapabilitiesConfirmation (Timestamp, Status, OSPVersion, OSPService*, Certif icateChain*, 

Deviceld?) > 
<!ATTLIST CapabilitiesConfirmation componentid ID #REQUIRED 

critical (true I false) #FIXED "false"> 

The CapabilitiesConfirmation message allows a server to specify the OSP capabilities that clients should use 
to communicate with it. It is sent in response to a Capabilities Indication. The information consists of a 
version number, an optional list of services supported, and an optional set of certificate chains. The version element 
specifies the version of OSP to which future communications shall conform. This version number shall be equal to or 
less than the version number proposed in the client's Capabilities Indication. The services list provides the 
client with information it needs to access various OSP services. The Certif icateChain elements provide 
certificate chains for public keys that the server will use to sign any authorization tokens it supplies. 

6.3 Elements 

This subclause defines the individual elements that make up each message component. 

6.3.1 Amount 

<! ELEMENT Amount (#PCDATA)> 

<!ATTLIST Amount critical (true I false) "true"> 

The Amount element identifies a numeric value and is often associated with the Increment and Unit elements, as 
well as the Currency element. Amounts are expressed using the period (.) as a decimal separator and with no 
punctuation as the thousands separator. The following excerpt, for example, expresses a rate of 50 cents (US) per 
minute. 

<Currency> 

USD 
</CurrencY> 
<Amount> 

0.5 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 



6.3.2 AuthorityURL 



<! ELEMENT AuthorityURL (#PCDATA)> 

<!ATTLIST AuthorityURL critical (true I false) "true"> 

The AuthorityURL element identifies a uniform resource locator (URL) by which authorization may be verified or 
refreshed. 

6.3.3 Callld 

<!ELEMENT Callld (#PCDATA)> 

<!ATTLIST Callld encoding (cdata I base64) "cdata" 
critical (true | false) "true"> 

The Callld element contains a call's ITU-T Recommendation H.323 [13] Callld value, and is thus used to uniquely 
identify individual calls. To convey its binary value, a call identifier may either be encoded using XML CDATA format 
and appropriate escape sequences, or it may be encoded with base64 encoding as per the [5] standard. An encoding 
attribute indicates the method selected, and the default value for that attribute is XML CDATA. 
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6.3.4 Code 

<! ELEMENT Code (#PCDATA)> 

<!ATTLIST Code critical (true i false) "true"> 

The Code element contains the numeric value that uniquely and unambiguously indicates the sender's response to a 
request or indication. It is usually paired with a Description element within a Status element. The Code content 
consists of three numeric digits in the form NNN. The first (most significant) digit indicates the success or failure of the 
operation, subsequent digits provide greater detail. Values defined by the present document include the following: 

NOTE: Subsequent revisions to the present document may add other code values, but will always preserve the 
meaning of a most significant 2 as success, and any other most significant digit as failure. 

2 XX = operation successful 

2 00 = success (no other information) 

2 01 = information created (no previous values) 

210 = updated information accepted (previous values replaced) 

4 XX = client error 

4 00 = bad request (generic problem interpreting message) 

401 = unauthorized 

402 = authentication unsuccessful 

403 = call authorization unsuccessful 

404 = route authorization unsuccessful 
410 = character encoding not supported 
411= parsing unsuccessful 

412 = critical element not supported 

4 2 = generic security problem (no other information available) 

4 21 = signature invalid 

4 22 = cryptographic algorithm not supported 

4 2 3 = certificate invalid 

4 2 4 = certificate revoked 

4 2 5 = encryption required 

5 XX = server error 

500 = internal server error 

5 01 = not implemented 

5 03 = service not available 

510 = transient problem in server 

52 = long term problem in server 

5 30 = time problem 

5 31 = valid time too soon 

5 32 = time interval too small 

999 = generic failure (no other information available) 



6.3.5 Currency 



<! ELEMENT Currency (#PCDATA)> 

<!ATTLIST Currency critical (true I false) "true"> 

The Currency element defines the financial currency in use for the parent element. It is represented according to the 
notation of ISO 4217 [7]. In addition, the following definitions not included in ISO 4217 [7] may be used: 

ECU European Currency Unit 

EUR Euro 

SDR Special Drawing Rights 
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6.3.6 Description 



<!ELEMENT Description (#PCDATA)> 

<!ATTLIST Description critical (true I false) "false"> 

The Description element provides a textual description for a response, and is typically paired with a Code element 
as part of a Status parent element. The Description element is for informational purposes only, as the Code 
element defines the behaviour. Suggested values for the Description element are the descriptions given above for 
each Code value. 

6.3.7 Destination 

<!ELEMENT Destination ( Destinationinf o?, DestinationAlternate*, DestinationSignalAddress, Token*, 

ValidAfter?, ValidUntil?, UsageDetail*, AuthorityURL*, Callld)> 
<!ATTLIST Destination critical (true I false) "true"> 

The Destination element is the parent element for call routing information, and it is returned by servers in an 
AuthorizationResponse messages. As the above definition shows, as many as nine different types of 
subelements may comprise a Destination element. 

6.3.8 DestinationAlternate 



<!ELEMENT DestinationAlternate (#PCDATA)> 








<!ATTLIST DestinationAlternate type ( el64 | h323 | url | email 


transport 






international I national 


network 






subscriber | abbreviated 


el64prefix ) 


♦REQUIRED 




critical ( true false ) 




"true" 


> 



The DestinationAlternate element contains secondary identification of the destination. This information 
provides an alternative to the Destinationinf o element. DestinationAlternate uses the same notation as 

Destination Info. 

6.3.9 Destinationlnfo 



<!ELEMENT Destinationlnfo (#PCDATA)> 








<!ATTLIST Destinationlnfo type ( el64 | h323 | url | email 


transport 






international national 


network 






subscriber | abbreviated 


el64prefix ) 


♦REQUIRED 




critical ( true I false ) 




"true" 


> 



The Destinationlnfo element gives the primary identification of the destination, or called party, for a call. The 
element includes a type attribute, and can take one of several forms depending on the value of that attribute. 

The following list indicates the contents of the element, given each possible attribute type. 

e 1 6 4 full ITU-T Recommendation E. 1 64 [12] telephone number containing numeric digits 

only (i.e. no punctuation) 
h 3 2 3 ITU-T Recommendation H.323 [ 1 3] identifier 

url Uniform Resource Locator [13] 

email electronic mail address [13] 

transport transport address is the form of name:nn where name is the domain name (or IP address 

enclosed in square brackets) and :nn is an (optional) TCP or UDP port number, 

(e.g. [172.16.1. 1]:112) 
international international party number [13] 

national national party number [13] 

network network specific party number [13] 

subscriber subscriber party number [13] 

abbreviated abbreviated party number [13] 

el64pref ix initial (most significant) digits of an ITU-T Recommendation E.164 [12] number with no 

punctuation 
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6.3.10 DestinationSignalAddress 

<!ELEMENT DestinationSignalAddress (#PCDATA)> 

<!ATTLIST DestinationSignalAddress critical (true I false) "true"> 

The DestinationSignalAddress element identifies the call signalling address for the destination. It is represented as 
name:nn, where name is a domain name or an IP address enclosed in square brackets. The :nn is optional and indicates a 
TCP port number. For example, call signalling to device gateway.operator.com at TCP port number 1 12 is represented 
as follows: 

<DestinationSignalAddress> 
gateway .operator . com: 112 
</DestinationSignalAddress> 



6.3.11 Increment 

<! ELEMENT Increment (#PCDATA)> 

<!ATTLIST Increment critical (true I false) "true"> 

The Increment element indicates the number of units being accounted. It is typically used in combination with the 
Amount and Unit elements. The following excerpt, for example, expresses a duration of 5'/2 minutes. 

<Amount> 

5.5 
< /Amount > 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 

6.3.12 MaximumDestinations 

<!ELEMENT MaximumDestinations (#PCDATA)> 

<!ATTLIST MaximumDestinations critical (true I false) "true"> 

The MaximumDestinations element appears in the AuthorizationRequest component to indicate the 
maximum number of potential destinations the client wishes to receive in the response. 

6.3.13 Role 

<! ELEMENT Role (#PCDATA)> 

<!ATTLIST Role critical (true | false) "true"> 

The Role element indicates the role of the system generating a message. It shall contain one of the following values: 

source message generated by source; 

destination message generated by destination; 

other message generated by systems other than source or destination. 
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6.3.14 Service 

<! ELEMENT Service ( Bandwidth? )> 

<!ATTLIST Service critical (true | false) "true"> 

The Service element indicates a type of service being priced, authorized, or reported. If present, the Bandwidth 
element indicates the bandwidth required for or consumed by the service. 



6.3.15 SourceAlternate 



<!ELEMENT SourceAlternate (#PCDATA) 


> 










<!ATTLIST SourceAlternate type 


( el64 1 h323 | url | email 
international I national 


transport 
network 










subscriber | abbreviated 


el64prefix 


iso7812 








pin 1 epin | deviceld ) #REQUIRED 








critical 


( true false ) 






"true" 


> 



The SourceAlternate element contains secondary identification of the source of a call. It conforms to the same 
notation as the Destinationlnfo element. 

The additional types specific to source information are iso7812, pin, and epin. They are defined as follows: 

i s o 7 8 1 2 ISO/IEC standard 7812-1 [30] identification card number containing numeric digits only (i.e. 

no punctuation) 
pin Personal identification number containing numeric digits only (i.e. no punctuation) 

epin Encrypted personal identification number, base64 encoded. The encryption procedure is as 

follows: 

1 . Pad the PIN, represented as ASCII decimal digits, with nulls (binary zeroes) to a multiple 
of 16 octets. 

2. Concatenate a 128-bit random number to the shared secret (shared by the OSP server and 
client). 

3. Calculate a one-way hash of the resulting concatenation using the Message Digest 5 
algorithm. 

4. Exclusive-OR the result with the padded PIN. 

5. Concatenate the resulting value after the original 128-byte random and base64 encode the 
resulting 256-byte quantity. 

deviceld server-assigned identifier. 

6.3.16 Sourcelnfo 



<!ELEMENT Sourcelnfo (#PCDATA) 


> 










<!ATTLIST Sourcelnfo type 


( el64 1 h323 


url 1 email 


transport 








international 


national 


network | subscriber 








abbreviated 


el64prefix 


iso7812 1 pin | epin 


deviceld ) 






♦REQUIRED 










critical 


( true 1 false ] 


1 




"true" 


> 



The Sourcelnfo element contains the primary identification of the source of a call. It uses the same notation as the 
Destinationlnfo element, along with the additional types defined for SourceAlternate. 

6.3.17 SourceSignalAddress 

<!ELEMENT SourceSignalAddress (#PCDATA)> 

<!ATTLIST SourceSignalAddress critical (true I false) "true"> 

The SourceSignalAddress element identifies the call signalling address of the source of a call. It uses the same 
notation as the DestinationSignalAddress element. 
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6.3.18 Status 

<!ELEMENT Status ( Code, Description? )> 
<!ATTLIST Status critical (true I false) "true"> 

The Status element reports the results of a response or confirmation. It is composed of a Code element and an 
optional Description element. 

For example, the following excerpt indicates a successful response or confirmation: 

<Status> 

<Code> 

200 
</Code> 
<Description> 

success (no other information) 
</Description> 
</Status> 



6.3.19 Timestamp 



<! ELEMENT Timestamp (#PCDATA)> 

<!ATTLIST Timestamp critical (true I false) "true"> 

The Timestamp element indicates the time at which the component was generated. It is represented by a restricted form 
of ISO 8601 [8] format. In particular, time is always represented in co-ordinated universal time (UTC) using the 
notation YYYY-MM-DDThh : mm : s s Z where: 

YYYY = four-digit year (for example, 1998); 

MM = two-digit month (01=January, etc.); 

DD = two-digit day of month (01 through 31); 

T = indicates division between date and time; 

hh = two-digit hour (00 through 23); 

mm = two-digit minute (00 through 59); 

ss = two-digit second (00 through 59); 

Z = indicates co-ordinated universal time. 

For example, exactly 3:03 P.M. on May 2, 1997, Eastern Daylight Time in the United States, is represented as: 

<Timestamp> 

1997-05-02T19:03:00Z 
</Timestamp> 

6.3.20 Token 

<! ELEMENT Token (#PCDATA)> 

<!ATTLIST Token encoding (cdata I base64) "cdata" 
critical (true \ false) "true"> 

The Token element conveys a security token. To convey its binary value, a token may either be encoded using XML 
CDATA format and appropriate escape sequences, or it may be encoded with base64 encoding as per the [5] standard. 
An encoding attribute indicates the method selected, and the default value for that attribute is XML CDATA. 

6.3.21 Transaction Id 

<!ELEMENT Transact ionid (#PCDATA)> 

<!ATTLIST Transactionid critical (true I false) "true"> 

The Transactionid element contains an integer, decimal valued identifier assigned to a specific authorized 
transaction. It is represented without any punctuation (e.g. no thousands separator). 
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6.3.22 Unit 

<! ELEMENT Unit (#PCDATA)> 

<!ATTLIST Unit critical (true i false) "true"> 

The Unit element indicates the units by which pricing is measured or usage recorded. It shall contain one of the 
following values: 

s seconds; 

pkt packets (datagrams); 

byte bytes. 



6.3.23 UsageDetail 



<!ELEMENT UsageDetail (Service, Amount, Increment, Unit, StartTime?, EndTime?, TerminationCause?, 

Statistics? )> 
<!ATTLIST UsageDetail critical (true I false) "true"> 

The UsageDetail element collects information describing the usage of a service. Individual transactions may 
combine multiple UsageDetail elements as part of their usage report. This capability supports both parallel services 
(e.g. audio and video streams during a video conference) and serial services (e.g. low bit-rate codec switching to a 
higher quality codec as network conditions deteriorate). 

The UsageDetail element may also be present in either an AuthorizationResponse or a 
ReauthorizationResponse. In that case, it indicates a limit to the authorization. For example, an 
AuthorizationResponse that includes a UsageDetail of (amount = 3, increment = 60, unit = s) indicates that 
the authorization is valid for no more than 3 minutes of service. 

6.3.24 ValidAfter 

<! ELEMENT ValidAfter (#PCDATA)> 

<!ATTLIST ValidAfter critical (true I false) "true"> 

The ValidAfter element identifies the time and date after which the component's information shall be effective or 
valid. It is encoded using the same notation as the Timestamp element. If this element is empty, component 
information is assumed to be valid as soon as it is received. 

6.3.25 ValidUntil 

<!ELEMENT ValidUntil (#PCDATA)> 

<!ATTLIST ValidUntil critical (true I false) "true"> 

The ValidUntil element identifies the time and date after which the component's information is no longer effective 
or valid. It is encoded using the same notation as the Timestamp element. If this element is empty, component 
information is assumed to be effective indefinitely, or until it is explicitly modified with new information. 

6.3.26 EndTime 

<! ELEMENT EndTime (#PCDATA)> 

<!ATTLIST EndTime critical (true I false) #FIXED "false"> 

The EndTime element indicates the time at which the service ended. It is encoded using the same notation as the 
Timestamp element. 



6.3.27 StartTime 



<! ELEMENT StartTime (#PCDATA)> 

<!ATTLIST StartTime critical (true I false) #FIXED "false"> 
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The StartTime element indicates the time at which the service started. It is encoded using the same notation as the 
Time St amp element. 

6.3.28 TCCode 

<! ELEMENT TCCode (#PCDATA)> 

<!ATTLIST TCCode critical (true | false) #FIXED "false"> 

The TCCode element contains the numeric value that uniquely and unambiguously indicates the internet telephony 
transaction's status code. It is usually paired with a Description element within a TerminationCause element. 
The TCCode content consists of four numeric digits in the form NNNN. The first (most significant) digit indicates the 
success (1) or failure (0) of the operation, subsequent digits provide greater detail. Values defined by the present 
document include the following: 

0001 = unallocated (unassigned) number; 

0002 = no route to specified transit network; 

0003 = no route to destination; 

0004 = send special information tone; 

0005 = misdialed trunk prefix; 
000 6 = channel unacceptable; 

0007 = call awarded and being delivered in an established channel; 

000 8 = preemption; 

000 9 = preemption - circuit reserved for re-use; 

1016 = normal call clearing; 

0017 = user busy; 

0018 = no user responding; 

0019 = no answer from user (user alerted); 
002 = subscriber absent; 

0021 = call rejected; 

0022 = number changed; 

002 6 = non-selected user clearing; 

002 7 = destination out of order; 

002 8 = invalid number format (address incomplete); 

002 9 = facility rejected; 

0030 = response to STATUS ENQUIRY; 

0031 = normal, unspecified; 

0032 = no circuit/channel unavailable; 
0038 = network out of order; 

003 9 = permanent frame mode connection out of service; 

004 = permanent frame mode connection operational; 
0041 = temporary failure; 

004 2 = switching equipment congestion; 

004 3 = access information discarded; 

004 4 = requested circuit/channel not available; 

004 6 = precedence call blocked; 

004 7 = resource unavailable, unspecified; 

004 9 = quality of service unavailable; 

005 = requested facility not subscribed; 
0053 = outgoing calls barred within CUG; 
0055 = incoming calls barred with CUG; 
005 7 = bearer capability not authorized; 

0058 = bearer capability not presently available; 

00 62 = inconsistency in designated outgoing access information and subscriber class; 

00 63 = service or option not available, unspecified; 

00 65 = bearer capability not implemented; 

00 66 = channel type not implemented; 

00 69 = requested facility not implemented; 
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007 = only restricted digital information bearer capability is available; 

007 9 = service or option nit implemented, unspecified; 

0081 = invalid call reference value; 

0082 = identified channel does not exist; 

0083 = a suspended call exists, but this call identity does not; 

0084 = call identity in use; 

0085 = no call suspended; 

008 6 = call having the requested call identity has been cleared; 

0087 = user not member of CUG; 

0088 = incompatible destination; 
00 90 = non-existent CUG; 

00 91 = invalid transit network selection; 

00 95 = invalid message, unspecified; 

00 96 = mandatory information element is missing; 

00 97 = message type non-existent or not implemented; 

00 98 = message not compatible with call state or message type non-existent or not implemented; 

00 99 = information element/parameter non-existent or not implemented; 

0100 = invalid information element contents; 

0101 = message not compatible with call state; 

0102 = recovery on timer expiry; 

0103 = parameter non-existent or not implemented, passed on; 

0110 = message with unrecognized parameter, discarded; 

0111 = protocol error, unspecified; 
012 7 = interworking, unspecified. 

6.3.29 TerminationCause 

<!ELEMENT TerminationCause (TCCode, Description?) > 

<!ATTLIST TerminationCause critical (true I false) #FIXED "false"> 

The TerminationCause element reports the results of an internet telephony transaction. It is composed of the 
TCCode element and an optional Description element. 

For example, the following excerpt indicates a successful termination cause: 

<TerminationCause> 
<TCCode> 
1016 
</TCCode 
<Description> 

normal call clearing 
</Description> 
</TerminationCause> 



6.3.30 Certificate 

<!ELEMENT Certificate (#PCDATA)> 

<!ATTLIST Certificate encoding (cdata I base64) "base64" 
critical (true I false) #FIXED "false"> 

This element contains a public key certificate. To convey its binary value, a certificate may either be encoded using 
XML CDATA format and appropriate escape sequences, or it may be encoded with base64 encoding as per the [5] 
standard. An encoding attribute indicates the method selected, and the default value for that attribute is base64. 

6.3.31 CertificateCinain 

<!ELEMENT Cert if icateChain (Certificate*) > 

<!ATTLIST Certif icateChain critical (true I false) #FIXED "false"> 

This element contains a certificate chain. The first certificate is the subject's certificate. It is followed by any 
intermediate certificate authorities (in order) and concludes with the certificate for the root authority. 
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6.3.32 OSPCapability 



<!ELEMENT OSPCapability (#PCDATA)> 

<!ATTLIST OSPCapability critical (true I false) #FIXED "false"> 

This element identifies a particular OSP capability that a server can provide to a client. Capabilities are identified by the 
name of the component that the client sends to the server to invoke them. A client that wishes to send 
AuthorizationRequest messages to a server, for example, would include the following XML in its 

Capabilitieslndication message. 

<OSPCapabiHty critical="false"> 

AuthorizationRequest 
<OSPCapabiHty> 

6.3.33 OSPService 

<!ELEMENT OSPService (OSPCapability, OSPServiceURL*, OSPSignatureRequired) > 
<!ATTLIST OSPService critical (true I false) #FIXED "false"> 

The OSPService element provides information a client needs to obtain a particular service from an OSP server. The 
specific service is identified by the OSPCapability element. OSPServiceURL elements, if present, indicate the 
URL(s) the client should use to request the service. They appear in order of decreasing priority (e.g. the primary URL 
appears first), and, if none are present in the OSPService element, then the client may rely on other means to obtain 
the information. (It may, for example, simply use the same URL it used for the Capabilitieslndication. 
Message.) The final element, OSPSignatureRequired, is a Boolean value that indicates whether or not the server 
requires that request for the specified service to the identified URLs to be digitally signed. This explicitly allows for a 
server to indicate one set of URLs for signed messages of a particular type and a different set for unsigned messages of 
that same type. When such an option is available, the decision as to whether or not to sign messages is an 
implementation choice for the client. One possible strategy would be to first attempt to use the unsigned option, falling 
back to the signed option if the server responds with a security error. 

6.3.34 OSPServiceURL 

<!ELEMENT OSPServiceURL (#PCDATA)> 

<!ATTLIST OSPServiceURL critical (true I false) #FIXED "false"> 

The OSPServiceURL element identifies the uniform resource locator (URL) a client should use for a particular OSP 

service. 

6.3.35 OSPSignatureRequired 

<!ELEMENT OSPSignatureRequired (#PCDATA)> 

<!ATTLIST OSPSignatureRequired critical (true I false) #FIXED "false"> 

The OSPSignatureRequired element indicates whether or not a server requires that requests for the indicated 
service be digitally signed. It shall contain one of the following values: 

true signatures are required; 
false signatures are not required. 
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6.3.36 OSPVersion 

<!ELEMENT OSPVersion (#PCDATA)> 

<!ATTLIST OSPVersion critical (true I false) #FIXED "false"> 

The OSPVersion element identifies the highest version of TS 101 321 that the sender is willing to support. The 
sender is assumed to support all publicly released versions of the specification up to and including the indicated value. 
For example, the following XML fragment indicates that the sender can support OSP versions 1.4.2, 1.4.3, and 2.1.1. 

<OSPVersion critical = "false"> 

2.1.1 
</OSPVersion> 



6.3.37 SubscriberAuthenticationlnfo 



<!ELEMENT SubscriberAuthenticationlnfo (#PCDATA)> 








<!ATTLIST SubscriberAuthenticationlnfo encoding (cdata 


base64) 


"cdata" 




critical (true 


false) 


#FIXED 


"false"> 



Opaque information that a server creates to confirm the authentication of a subscriber. The server returns this element as 
part of the SubscriberAuthenticationResponse message, and clients should include it in subsequent 
AuthorizationRequest messages for the subscriber. 

6.3.38 Devicelnfo 




The Devicelnfo element allows a device to identify itself to a server when sending a 

Capabilitieslndication message. In addition to the standard Sourceinf o types, clients may use the 
following types to identify themselves: 

serialnumber manufacturer's serial number or equivalent for the device 
customer Id user-assigned value for the device. 

6.3.39 Deviceld 

<!ELEMENT Deviceld (#PCDATA) > 

<!ATTLIST Deviceld critical (true I false) "false" > 

The Deviceld element allows a server to provide an identifier to a client in a CapabilitiesConf irmation 
message. The client may then use that identifier in subsequent messages to the server. 

6.3.40 Resources 

<!ELEMENT Resources ( DataRate?, AlmostOutOf Resources? ) > 
<!ATTLIST Resources critical ( true I false ) #FIXED "false" > 

The Resources element allows a client to indicate its resources and their current status, as part of a 
Capabilitieslndication message. 

6.3.41 DataRate 

<!ELEMENT DataRate ( NumberOf Channels?, Bandwidth ) > 

<!ATTLIST DataRate critical ( true I false ) #FIXED "false" > 



DataRate describes the load that the client can handle. 
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6.3.42 NumberOfChannels 

<! ELEMENT NumberOfChannels (#PCDATA) > 

<!ATTLIST NumberOfChannels critical (true I false) #FIXED "false" > 

The NumberOfChannels element is positive integer, indicating the number of channels available on the client to 
service calls for a particular protocol. 

6.3.43 Bandwidth 

<! ELEMENT Bandwidth (#PCDATA) > 

<!ATTLIST Bandwidth critical (true I false) #FIXED "false" > 

The Bandwidth element is a positive integer. When the NumberOfChannels element is present, it indicates the 
available bandwidth (in bits/sec) of each channel on the client to service calls for a particular protocol. When the 
NumberOfChannels element is not present. Bandwidth represents the total bandwidth (in bits/sec). 

6.3.44 AlmostOutOfResources 

<!ELEMENT AlmostOutOfResources (#PCDATA) > 

<!ATTLIST AlmostOutOfResources critical (true I false) #FIXED "false" > 

The AlmostOutOfResources element is a flag from the client to the server. It shall contain one of the following 
values: 

true if the client might run out of resources shortly to accept new calls 
false if the client has sufficient resources to accept new calls. 



Signature Format 



If present, the digital signature within OSP shall conform to the application/pkcs7-signature format specified in the 
Secure Multipurpose Internet Mail Extensions (S/MIME) standard [18]. This clause specifies how that signature is 
created, including the canonicalization procedure, signature algorithm, and transfer encoding. 

7.1 Canonical Form 

Digital signatures described in the present document are signatures of the entire, transmitted XML document, beginning 
with (and including) the leftmost "<" of the XML declaration and ending with (and including) the rightmost ">" of the 
end tag of the root XML entity. Furthermore, conforming implementations should construct their XML documents 
using the following procedures to arrive at a canonical form. Such a form will enable the reconstruction of an XML 
document (and the verification of a digital signature) from the abstract information of the document. 

NOTE 1 : The following procedure borrows heavily from the Internet Open Trading Protocol (IOTP) 
specification [25]. 

1) Isolate the element to be signed. For the present document, this consists of the entire XML document, 
beginning with the leftmost "<" of the XML declaration and ending with (and including) the rightmost ">" of 
the end tag of the root XML entity; 

2) convert all characters in the element to canonical form for the character encoding; 

3) apply all external XML entities and all character and entity references in the element so that they are 
completely resolved; 

4) exclude comments and processing instructions; 
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5) reduce all attributes to their canonical form using the attribute type in the Document Type Definition (DTD). 
Replace all single and double quotes present in attributes with &#3 9; and " respectively so that attributes 
can be enclosed in double quotes; 

6) create attributes, using their default value, which are not present in the original but have default values in the 
DTD; 

7) sort the original and generated attributes in ascending attribute name order according to character encoding of 
the attribute name; 

8) for whitespace inside markup but not inside attribute values, generate it as minimally as possible. Specifically, 
(1) remove non-essential whitespace, and (2) represent required whitespace by a single space character; 

9) generate the content of all start tags using only the element name and the attributes as described above. If the 
element is an empty element, then generate it using the single empty tag format (i.e. a trailing slash). Generate 
end tags using only element name with no added whitespace; 

10) remove all whitespace in the element content; 

11) assemble start tags, end tags, empty tags, CD ATA sections, and text sections in the same order as the original 
document. 

NOTE 2: The above procedure results in a canonicalized XML document rather than a canonicalized MIME text 
part. In particular, the line ending is encoded as a single line-feed character (#xA) rather than the 
S/MIME convention of a return/line-feed pair. 



7.2 Signature Algorithms 



Annex B provides a list of cryptographic algorithms required and recommended by the present document, including 
S/MIME signature algorithms. 



7.3 Transfer Encoding 



Unlike some electronic mail protocols, HTTP is capable of transferring raw binary data. Consequently, no transfer 
encoding (e.g. quoted-printable or base-64) shall be used for the signature. 



8 Protocol Behaviour 

This clause specifies the relationship between the OSP message components. It defines message sequencing 
interdependence of messages, and exception handling. 



8.1 Message Sequencing 



The present document specifies a simple client/server protocol. All protocol exchanges shall be initiated by clients, who 
send one or more of the eight client components in a single message. The server shall reply with its own single message, 
which contains one server component for each client component. Figure 4 shows the seven different component pairs. 

When multiple components are combined in a single message, each component shall be treated independently of all 
others in the message. Logically, this treatment shall have the same effect as if each component is carried in its own 
message. 

In addition, each component exchange shall be considered independent of all others; there shall be no dependence 
between message exchanges. This is true even of Authorization exchanges. Specifically, both 
Authorizationlndication/Confirmation and ReauthorizationRequest/Response exchanges may refer to authorization 
previously obtained through means other than an AuthorizationRequest and AuthorizationResponse. 
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8.2 Exception Handling 

Systems conforming to the present document should use all levels of error handling available in the present document. 

8.2.1 Transmission Control Protocol 

If TCP indicates that communication cannot be established, or that communication has failed during a transmission, the 
communicating parties should not assume the delivery of any partial information. 

8.2.2 Secure Socket Layer/Transport Layer Security 

If SSL or TLS indicates that compatible encryption parameters cannot be established, the communicating parties should 
not assume the delivery of any partial information. In addition, if SSL/TLS is unable to successfully authenticate the 
server, the client should not proceed with the transfer of any information. 
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8.2.3 Hypertext Transfer Protocol 



Communicating parties should treat HTTP status codes as defined in RFC 1945 [2]. In particular, unless the status code 
is in the range 200-299, the client should not assume delivery of any information. 
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Figure 4: Component Pairs 

8.2.4 Status Element 

XML Code elements within responses and confirmations should be treated appropriately according to the definitions of 
subclause 6.3.3. The associated Description element should be used solely for informational purposes. 
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Annex A (normative): 
Document Type Definition 



This annex contains the complete XML document type definition for the messages described in the present document. 
The information is repeated from clause 6 and annex C, but is collected in one place for convenience of reference. 

<!ELEMENT Message ( ( Pricinglndication | PricingConf irmation | AuthorizationRequest 
AuthorizationResponse I Authorizationlndication | AuthorizationConf irmation | Usagelndication 
UsageConf irmation | ReauthorizationRequest I ReauthorizationResponse 

SubscriberAuthenticationRequest I SubscriberAuthenticationResponse I Capabilitieslndication 
CapabilitiesConf irmation )+ )> 
<!ATTLIST Message messageld ID #REQUIRED 

random CDATA #REQUIRED> 
<!ELEMENT Pricinglndication ( Timestamp, Sourcelnfo, Destinationlnfo, Currency, Amount, Increment, 
Unit, Service, ValidAfter, ValidUntil )> 
<!ATTLIST Pricinglndication componentid ID #REQUIRED> 
<! ELEMENT PricingConf irmation ( Timestamp, Status )> 
<!ATTLIST PricingConf irmation componentid ID #REQUIRED> 

<!ELEMENT AuthorizationRequest ( Timestamp, Callld+, Sourcelnfo, SourceAlternate*, Destinationlnfo, 
DestinationAlternate*, Service, MaximumDestinations, Token*, SubscriberAuthenticationInf o* )> 
<!ATTLIST AuthorizationRequest componentid ID #REQUIRED> 

<!ELEMENT AuthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination* )> 
<!ATTLIST AuthorizationResponse componentid ID #REQOIRED> 

<!ELEMENT Authorizationlndication ( Timestamp, Role, Callld, Sourcelnfo, SourceAlternate*, 
Destinationlnfo, DestinationAlternate*, Service, Token* )> 
<!ATTLIST Authorizationlndication componentid ID #REQDIRED> 

<!ELEMENT AuthorizationConf irmation ( Timestamp, Status, ValidAfter, ValidUntil )> 
<!ATTLIST AuthorizationConf irmation componentid ID #REQUIRED> 

<! ELEMENT Usagelndication ( Timestamp, Role, Transactionid, Callld, Sourcelnfo, SourceAlternate*, 
Destinationlnfo, DestinationAlternate*, UsageDetail*) > 
<!ATTLIST Usagelndication componentid ID #REQUIRED> 
<! ELEMENT UsageConf irmation ( Timestamp, Status )> 
<!ATTLIST UsageConf irmation componentid ID #REQUIRED> 

<!ELEMENT ReauthorizationRequest ( Timestamp, Role, Callld, Sourcelnfo?, SourceAlternate*, 
Destinationlnfo?, DestinationAlternate*, Transactionid, UsageDetail*, Token* )> 
<!ATTLIST ReauthorizationRequest componentid ID #REQUIRED> 

<!ELEMENT ReauthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination* )> 
<!ATTLIST ReauthorizationResponse componentid ID #REQUIRED> 

<!ELEMENT SubscriberAuthent icat ionRequest (Timestamp, Sourcelnfo, SourceAlternate*, 
Destinationlnfo?, Service?) > 

<!ATTLIST SubscriberAuthenticationRequest componentid ID #REQUIRED> 

<!ELEMENT SubscriberAuthent icat ionResponse (Timestamp, Status, SubscriberAuthenticationlnfo*) > 
<!ATTLIST SubscriberAuthenticationResponse componentid ID #REQUIRED> 

<!ELEMENT Capabilitieslndication (Deviceinf o*, OSPVersion, OSPCapability*, Resources*) > 
<!ATTLIST Capabilitieslndication componentid ID #REQUIRED 

critical ( true I false ) #FIXED "false"> 
<!ELEMENT CapabilitiesConf irmation (Timestamp, Status, OSPVersion, OSPService*, Certif icateChain*, 
Deviceld?) > 
<!ATTLIST CapabilitiesConf irmation componentid ID #REQUIRED 

critical (true I false) #FIXED "false"> 
<! ELEMENT Amount (#PCDATA)> 

<!ATTLIST Amount critical (true I false) "true"> 
<! ELEMENT AuthorityURL (#PCDATA)> 

<!ATTLIST AuthorityURL critical (true I false) "true"> 
<!ELEMENT Callld (#PCDATA)> 
<!ATTLIST Callld encoding (cdata I base64) "cdata" 

critical (true I false) "true"> 
<! ELEMENT Code (#PCDATA)> 

<!ATTLIST Code critical (true | false) "true"> 
<! ELEMENT Currency (#PCDATA)> 

<!ATTLIST Currency critical (true I false) "true"> 
<!ELEMENT Description (#PCDATA)> 

<!ATTLIST Description critical (true I false) "false"> 

<!ELEMENT Destination ( Destinationlnfo?, DestinationAlternate*, DestinationSignalAddress, Token*, 
ValidAfter?, ValidUntil?, UsageDetail*, AuthorityURL*, Callld )> 
<!ATTLIST Destination critical (true I false) "true"> 
<!ELEMENT DestinationAlternate (#PCDATA)> 

<!ATTLIST DestinationAlternate type ( el64 | h323 I url | email I transport I international 
national I network | subscriber | abbreviated I el64prefix ) #REQUIRED 

critical ( true I false ) "true" > 
<!ELEMENT Destinationlnfo (#PCDATA)> 

<!ATTLIST Destinationlnfo type ( el64 | h323 I url | email I transport I international I national 
network \ subscriber | abbreviated I el64prefix ) #REQUIRED 
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critical ( true I false ) "true" > 
<!ELEMENT Dest inat ionSignalAddress (#PCDATA)> 

<!ATTLIST DestinationSignalAddress critical (true I false) "true"> 
<! ELEMENT Increment (#PCDATA)> 

<!ATTLIST Increment critical (true I false) "true"> 
<!ELEMENT MaximumDest inat ions (#PCDATA)> 

<!ATTLIST MaximumDestinations critical (true I false) "true"> 
<! ELEMENT Role (#PCDATA)> 

<!ATTLIST Role critical (true | false) "true"> 
<! ELEMENT Service ( Bandwidth? )> 

<!ATTLIST Service critical (true I false) "true"> 
< [ELEMENT SourceAlternate (#PCDATA)> 

<!ATTLIST SourceAlternate type ( el64 | h323 I url | email I transport | international I national 
network i subscriber 1 abbreviated I el64prefix | iso7812 | pin | epin | deviceld ) #REQUIRED 

critical ( true I false ) "true" > 
<!ELEMENT Sourcelnfo (#PCDATA)> 

<!ATTLIST Sourcelnfo type ( el64 | h323 I url | email I transport I international I national 
network | subscriber | abbreviated I el64prefix | iso7812 | pin | epin | deviceld ) #REQUIRED 

critical ( true 1 false ) "true" > 
<!ELEMENT SourceSignalAddress (#PCDATA)> 

<!ATTLIST SourceSignalAddress critical (true I false) "true"> 
<!ELEMENT Status ( Code, Description? )> 
<!ATTLIST Status critical (true | false) "true"> 
<! ELEMENT Timestamp (#PCDATA)> 

<!ATTLIST Timestamp critical (true I false) "true"> 
<! ELEMENT Token (#PCDATA)> 
<!ATTLIST Token encoding (cdata I base64) "cdata" 

critical (true 1 false) "true"> 
<!ELEMENT Transact ionid (#PCDATA)> 

<!ATTLIST Transactionid critical (true I false) "true"> 
<! ELEMENT Unit (#PCDATA)> 

<!ATTLIST Unit critical (true I false) "true"> 

<!ELEMENT UsageDetail (Service, Amount, Increment, Unit, StartTime?, EndTime?, TerminationCause?, 
Statistics? )> 

<!ATTLIST UsageDetail critical (true I false) "true"> 
<! ELEMENT ValidAfter (#PCDATA)> 

<!ATTLIST ValidAfter critical (true I false) "true"> 
<!ELEMENT ValidUntil (#PCDATA)> 

<!ATTLIST ValidUntil critical (true I false) "true"> 
<! ELEMENT EndTime (#PCDATA)> 

<!ATTLIST EndTime critical (true | false) #FIXED "false"> 
<! ELEMENT StartTime (#PCDATA)> 

<!ATTLIST StartTime critical (true I false) #FIXED "false"> 
<! ELEMENT TCCode (#PCDATA)> 

<!ATTLIST TCCode critical (true I false) #FIXED "false"> 
<!ELEMENT TerminationCause (TCCode, Description?) > 

<!ATTLIST TerminationCause critical (true I false) #FIXED "false"> 
<!ELEMENT Certificate (#PCDATA)> 
<!ATTLIST Certificate encoding (cdata I base64) "base64" 

critical (true I false) #FIXED "false"> 
<!ELEMENT Cert if icateChain (Certificate* ) > 

<!ATTLIST Certif icateChain critical (true I false) #FIXED "false"> 
<! ELEMENT OSPCapability (#PCDATA)> 

<!ATTLIST OSPCapability critical (true I false) #FIXED "false"> 
<!ELEMENT OSPService (OSPCapability, OSPServiceURL*, OSPSignatureRequired) > 
<!ATTLIST OSPService critical (true I false) #FIXED "false"> 
<!ELEMENT OSPServiceURL (#PCDATA)> 

<!ATTLIST OSPServiceURL critical (true I false) #FIXED "false"> 
<!ELEMENT OSPSignatureRequired (#PCDATA)> 

<!ATTLIST OSPSignatureRequired critical (true I false) #FIXED "false"> 
<!ELEMENT OSPVersion (#PCDATA)> 

<!ATTLIST OSPVersion critical (true I false) #FIXED "false"> 
<!ELEMENT SubscriberAuthent icat ioninf o (#PCDATA)> 
<!ATTLIST SubscriberAuthenticationInf o encoding (cdata I base64) "cdata" 

critical (true I false) #FIXED "false"> 
<!ELEMENT Devicelnfo (#PCDATA) > 

<!ATTLIST Devicelnfo type ( el64 | h323 I url | email I transport I serialnumber | customerld ) 
#REQUIRED 

critical ( true I false ) #FIXED "false" > 
<!ELEMENT Deviceld (#PCDATA) > 

<!ATTLIST Deviceld critical (true I false) "false" > 
<!ELEMENT Resources ( DataRate?, AlmostOutOf Resources? ) > 
<!ATTLIST Resources critical ( true I false ) #FIXED "false" > 
<!ELEMENT DataRate ( NumberOf Channels?, Bandwidth ) > 
<!ATTLIST DataRate critical ( true I false ) #FIXED "false" > 
<! ELEMENT NumberOf Channels (#PCDATA) > 

<!ATTLIST NumberOfChannels critical (true I false) #FIXED "false" > 
<! ELEMENT Bandwidth (#PCDATA) > 
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false) #FIXED 


"false"> 


false) #FIXED ' 


false"> 


false) #FIXED 


"false"> 


raction )> 





ATTLIST Bandwidth critical (true I false) #FIXED "false" > 

ELEMENT AlmostOutOf Resources (#PCDATA) > 

ATTLIST AlmostOutOfResources critical (true I false) #FIXED "false" > 

ELEMENT Statistics ( LossSent?, LossReceived?, OneWayDelay?, RoundTripDelay? )> 

ATTLIST Statistics critical (true I false) #FIXED "false"> 

ELEMENT LossSent ( Packets, Fraction )> 

ATTLIST LossSent critical (true 

ELEMENT Packets (#PCDATA)> 

ATTLIST Packets critical (true 

ELEMENT Fraction (#PCDATA)> 

ATTLIST Fraction critical (true 

ELEMENT LossReceived ( Packets, Fraction 

ATTLIST LossReceived critical (true I false) #FIXED "false"> 

ELEMENT OneWayDelay ( Minimum, Mean, Variance, Samples )> 

ATTLIST OneWayDelay critical (true I false) #FIXED "false"> 

ELEMENT Minimum (#PCDATA)> 

ATTLIST Minimum critical (true | false) #FIXED "false"> 

ELEMENT Mean (#PCDATA)> 

ATTLIST Mean critical (true I false) #FIXED "false"> 

ELEMENT Variance (#PCDATA)> 

ATTLIST Variance critical (true I false) #FIXED "false"> 

ELEMENT Samples (#PCDATA)> 

ATTLIST Samples critical (true I false) #FIXED "false"> 

ELEMENT RoundTripDelay ( Minimum, Mean, Variance, Samples )> 

ATTLIST RoundTripDelay critical (true I false) #FIXED "false"> 
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Annex B (normative): 
Cryptographic Algorithms 



For convenience and ease of reference, this annex provides the specification of cryptographic algorithms referenced in 
the standard. Cryptographic algorithms are essential to SSL/TLS communications, S/MIME signatures, and token 
formats. 



B.1 SSL/TLS CipherSuites 



Systems conforming to the present document may negotiate any mutually supported SSL/TLS CipherSuite using the 
standard SSL/TLS handshake mechanisms. To ensure maximum interoperability, all compliant systems should support 
the SSL_RSA_WITH_3DES_EDE_CBC_SHA CipherSuite. In environments where triple DES data encryption is not 
desired or is otherwise unavailable, systems should support the SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 
CipherSuite. If no data encryption is desired or available, systems should use the SSL_RSA _WITH_NULL_SHA 
CipherSuite. 



B.2 S/IVIIIVIE Signatures 



Communicating systems may use any digest and signing algorithms defined by the S/MIME standard [18]. To ensure 
interoperability, all compliant systems shall support the Secure Hash Algorithm (SHA) [17] for message digests, and 
the Digital Signature Algorithm (DSA) [16] for signing. 

NOTE: To take maximum advantage of deployed cryptographic software, systems should also support the 
Message Digest 5 (MD5) digest algorithm [20] and the Rivest Shamir Adleman (RSA) signature 
algorithm [21]. 



B.3 Tokens 



Tokens used for authorization, call progress, and call completion may be signed and encrypted. For message digest, 
signing, and encryption, implementations may use any algorithm defined by the Public Key Cryptography Standard #7 
(PKCS7) [22]. To ensure interoperability, systems should support Secure Hash Algorithm [17], Diffie-Hellman key 
exchange [1], Digital Signature Algorithm [16], and the Data Encryption Standard [15]. 

NOTE: To take maximum advantage of deployed cryptographic software, systems should also support the 
Message Digest 5 [20], Rivest Shamir Aldeman [21], and Rivest Cipher 2 [19] algorithms. 
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Annex C (normative): 
Enhanced Usage Reports 



The following optional Enhanced Usage elements may be added to the UsageDetail element of Usagelndication 

messages. 

C.1 Enhanced Usage Elements 

The definition of Enhanced Usage elements, and the definition of sub-elements, follows: 

C.1.1 statistics 

<!ELEMENT Statistics ( LossSent?, LossReceived?, OneWayDelay?, RoundTripDelay? )> 
<!ATTLIST Statistics critical (true I false) #FIXED "false"> 

The Statistics element collects network performance statistics for the call. It may include packet loss statistics (in 
either direction) and delay statistics (one-way or round trip.) The entire element is non-critical, and may thus be safely 
ignored by systems that do not support it. 

C.1.2 LossSent 

<!ELEMENT LossSent ( Packets, Fraction )> 

<!ATTLIST LossSent critical (true I false) #FIXED "false"> 

The LossSent element contains packet loss information for datagrams transmitted by the reporting system that were 
not received by its peer, as reported in the peer's RTCP sender and receiver reports. It includes the two sub-elements 
indicated above and described in the following subsections. 

C.1.3 Packets 

<!ELEMENT Packets (#PCDATA)> 

<!ATTLIST Packets critical (true I false) #FIXED "false"> 

The Packets element contains a count of the total number of packets. The value is formatted as a decimal number 
without punctuation. 



C.1.4 Fraction 



<!ELEMENT Fraction (#PCDATA)> 

<!ATTLIST Fraction critical (true I false) #FIXED "false"> 

The Fraction element contains a value for a fraction of packets, expressed as an integer number from (no packets) 
to 255 (all packets), and it is formatted as a decimal number without punctuation. 



C.1.5 LossReceived 



<!ELEMENT LossReceived ( Packets, Fraction )> 

<!ATTLIST LossReceived critical (true I false) #FIXED "false"> 

The LossReceived element contains packet loss information for datagrams that should have been received by the 
reporting system receive but were not, as reported in the system's RTCP sender and receiver reports. It includes the two 
sub-elements indicated above and described in the previous subsections. 



C.1.6 OneWayDelay 



<! ELEMENT OneWayDelay ( Minimum, Mean, Variance, Samples )> 
<!ATTLIST OneWayDelay critical (true I false) #FIXED "false"> 

The OneWayDelay element reports measurements of one way delay to the reporting system/ro/w its peer, as measured 
during the communication. It is suggested that the measurement be made by comparing the network time protocol 
(NT?) timestamp included in RTCP messages sent by the peer with the local NTP time. The element consists of the 
following four sub-elements. 
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C.1.7 Minimum 



<! ELEMENT Minimum (#PCDATA)> 

<!ATTLIST Minimum critical (true I false) #FIXED "false"> 

The Minimum element reports the minimum measured value, expressed in milliseconds. It is formatted as an 
integer decimal number without punctuation. 



C.1.8 IVIean 

<! ELEMENT Mean (#PCDATA)> 

<!ATTLIST Mean critical (true I false) #FIXED "false"> 

The Mean element reports the statistical mean of all measured values. It is expressed in milliseconds, and it is formatted 
as an integer decimal number without punctuation. 

C.1.9 Variance 

<!ELEMENT Variance (#PCDATA)> 

<!ATTLIST Variance critical (true I false) #FIXED "false"> 

The Variance element reports the statistical variance of all measured values. It is expressed in squared milliseconds, 
and it is formatted as an integer decimal number without punctuation. 



C.1.10 Samples 



<! ELEMENT Samples (#PCDATA)> 

<!ATTLIST Samples critical (true I false) #FIXED "false"> 

The Samples element reports the number of samples measured by the reporting system. It is formatted as a decimal 
number without punctuation. 



C.1.11 RounclTripDelay 



<! ELEMENT RoundTripDelay ( Minimum, Mean, Variance, Samples )> 
<!ATTLIST RoundTripDelay critical (true I false) #FIXED "false"> 

The RoundTripDelay element reports measurements of round trip delay between the reporting system and its peer, 
as measured during the communication. Such measurements may be made, for example, by 
ITU-T Recommendation H.245 [10] round trip delay exchanges during the call. The element consists of the four 
sub-elements described above. 
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Annex D (informative): 
Token Formats 



This annex presents suggested formats for authorization tokens included in the authorization information defined in the 
present document. Once obtained by an endpoint, such tokens may be passed as part of the call signalling exchange. 
The annex describes suggested cryptographic encodings as well as suggested contents for these authorization tokens, 
and it identifies methods for carrying tokens within call signalling protocols. The final section shows a complete, 
sample token. 



D.1 Cryptographic Encoding 



Depending on the business roles and network environment, tokens may be digitally signed and/or encrypted. If digitally 
signed, tokens should conform to Cryptographic Message Syntax (CMS) specification [28] for signed-data content. If 
encrypted, tokens should conform to the CMS specification for enveloped-data content. If tokens are both signed and 
encrypted, they should be constructed in two phases. First, the token should be digitally signed, resulting in CMS 
signed-data content. The resulting signed content should then be encrypted, resulting in CMS enveloped-data content. 

If the token syntax and semantics are understood by all relevant parties, then authorization tokens may use the generic 
id-data OBJECT IDENTIFER (1.2.480.113549.1.7.1) as the data content type. If a token contents are consistent with 
one of the formats described in this annex, and if the token wishes to explicitly identify that format, it may use one of 
the following object identifiers as the data content type: 

osp-token-contents-asnl OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token-contents(2) 1 } 

osp-token-contents-xml OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token-contents(2) 2 } 

osp-token-contents-bxml OBJECT IDENTIFER ::= { itu-t(O) identified -organization(4) etsi(O) ts-101 -32 1(1321) 
token-contents(2) 3 } 

Annex B documents the cryptographic algorithms recommended by the present document, including digest, signing, 
symmetric encryption, and asymmetric encryption algorithms. 

To minimize the size of resulting tokens, appropriate certificates may be conveyed to endpoints as part of the 
capabiiitiesConf irmaion message, and the optional CMS CertificateSet information element may be omitted from 
individual tokens. In such cases, the most efficient way to identify the signer is to use the SubjectKeyldentifier, where 
its contents are a SHA-1 hash of the signer's public key. An example of such a token is: 

SignedData ::= SEQUENCE { 

version CMSVersion, version 3 

digestAlgorithms DigestAlgorithmldentifiers, e.g. md5 (1.2.840.113594.2.5) 

encapContentlnformation EncapsulatedContentlnfo, e.g. osp-token-contents-bxml 

signerlnfos Signerlnfos } see below 

Where, the Signerlnfos consists of the following single element: 

Signerlnfo ::= SEQUENCE { 

version CMSVersion, version 3 

sid Signerldentifier, see below 

digestAlgorithmDigestAlgorithmldentifier, e.g. md5 (1.2.840.113594.2.5) 

signatureAlgorithm SignatureAlgorithmldentifier, e.g. rsa (1.2.840.113594.1.1.1) 

signature SignatureValue } 128-octet signature 

And the Signerldentifier element is: 

Signerldentifier ::= CHOICE { 

SubjectKeyldentifier [0] } 20-octet SHA-1 hash of signer' s public key 

This encoding will result in a token whose size is about 250 octets plus the size of the signed contents. 
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NOTE: The SubjectKeyldentifier element may be used even when the signer's public key certificate does not 

explicitly include that specific extended attribute, as the recipient will be able to compute the appropriate 
value from the certificate's public key. 



D.2 Token Content 

This clause suggests two different token formats. The ASN.l format relies on information elements defined in the ITU- 
T Recommendation H.323 [13] standards, and is appropriate for native H.323 [13] systems. The XML format is 
consistent with the body of the present document, and may be used where ASN. 1 encoding/decoding is not available or 
desired. The Binary XML format is a more compact representation of the XML format. 

D.2.1 ASN.1 Format 

The actual content of the token may conform to the following ASN.l specifications, as augmented by ASN.l constructs 
from the ITU-T Recommendation H.323 [13] standards [13], [9], [14], and [10]. The tokens should be encoded using 
the Packed Encoding Rules (Aligned) of ITU-T Recommendation X.691 [11]. 



ETSI-TIPHON-TOKENS DEFINITIONS AUTOMATIC TAGS 

BEGIN 

IMPORTS 

AliasAddress, 

Callldentifier, 

ReleaseCompleteReason, 

TimeStamp 
FROM H323-MESSAGES; 
ServiceDescription : : = CHOICE 
{ 



basicTelephony 
ve ndor Specif ic 



NULL, 
NonStandardParameter, 



MeasureUnits : : CHOICE 



seconds 

packets 

bytes 

ve ndor Specif ic 



NULL, 
NULL, 
NULL, 
NonStandardParameter, 



UsageData 
{ 



SEQUENCE 



amount 

units 

increment 

ve ndor Specif ic 



INTEGER (0. .4294967295) ) , 

MeasureUnits, 

INTEGER (1. .4294967295) , 

NonStandardParameter, 



AuthorizationToken : : 

{ 

random 

sourceinf o 

destinationlnfo 

callld 

validAfter 

validUntil 

transactionid 

serviceAuthorized 



{ 



service 
limit 



author it yURL 
ve ndor Specif ic 



SEQUENCE 

INTEGER (1. .4294967295) , 
SEQUENCE OF AliasAddress, 
SEQUENCE OF AliasAddress, 
Callldentifier OPTIONAL, 
TimeStamp OPTIONAL, 
TimeStamp OPTIONAL, 

OCTET STRING (SIZE (16)) OPTIONAL, 
SEQUENCE OF SEQUENCE 

ServiceDescription, 

UsageData OPTIONAL 

OPTIONAL, 

SEQUENCE OF IA5String (SIZE (1 .. 512) ) OPTIONAL, 

NonStandardParameter OPTIONAL, 



END 



of ASN. 1 
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D.2.2 XML Format 

Authorization tokens may also be constructed in XML as a standalone XML document. The root element of such a 
document shall be Tokeninf o, and it shall conform to the following construction: 

<!ELEMENT Tokenlnfo ( Sourcelnfo?, SourceAlternate*, Destinationinf o?, DestinationAlternate*, 
Callld*, ValidAfter?, ValidUntil?, Transactionid?, UsageDetail*, 
AuthorityURL* )> 

<!ATTLIST Tokenlnfo random #REQUIRED> 

The individual elements of the document, including any private or future extensions, shall conform to the body of the 
present document. The following text illustrates an example XML token: 

<TokenInfo random=" 12345678 "> 

<SourceInfo type="el64 ">814 58811202</Sourcelnf o> 
<DestinationInfo type="el 64 ">47 668413 60</Destlnationlnfo> 
<CallId encoding=base64>Aadf9811asdfA8adooif7c3nnsa8 9</CallId> 
<ValidAfter>1998-04-24T17 : 01 : 01Z</ValidAfter> 
<ValidUntil>1998-04-24T17 : 11 : 01Z</ValidUntil> 
<TransactionId>6772374</TransactionId> 
<UsageDetail> 

<Service/> 

<Amount > 2 4 < /Amount > 

<Increment>3 60 0</Increment> 

<Unit>s</Unit> 
</UsageDetail> 
</TokenInfo> 



D.2.3 Binary XML Format 



Binary XML (see annex H) provides a more compact representation of XML documents, and may be applied to 
authorization token contents. The contents of the token of D.2.2, when represented as Binary XML according to the 
rules of annex H, are as follows: 



02 01 03 00 

F6 OB 03 '12345678' 00 

EE OF 01 03 '81458811202' 00 01 
D6 OF 01 03 '4766841360' 00 01 
CD 8 01 03 

'Aadf9811asdfA8adooif7c3nnsa89' 00 01 
7D 03 '1998-04-24T17:01:01Z' 00 01 
7E 03 '1998-04-24T17:ll:01Z' 00 01 
78 03 '6772374' 00 01 



7E 



01 



2C 

46 03 '24' 00 01 

5C 03 '3600' 00 01 

79 03 's' 00 01 



01 



D.3 Token Carriage 



When carried as part of a call signalling message of an ASN. 1 -based protocol, authorization tokens may be identified 
by one of the following object identifiers. The first value is for tokens with self-identifying or otherwise unspecified 
formats. 

osp-token OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) token (1) } 

osp-token-asnl -format OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101 -32 1(1321) 
token (1) 1 } 

osp-token-xml-format OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token(l) 2 } 

osp-token-bxml-format OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token(l) 3 } 
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When carries as part of a call signalling message of a MIME-based protocol, authorization tokens may be identified by 
the following MIME type: 

MIME media type name: x-application 
MIME subtype name: x-osp-token 
Required parameters: none 
Optional parameters : 

x-osp-token-f ormat : a value of "asn.l" indicates the token contents use the ASN.l format 
defined in annex D, section D.2.1 of the OSP specification; a value of "xml" 
indicates the token contents use the XML format defined in annex D, section D.2.2 of 
the OSP specification, and a value of "bxml" indicates the token contents use the 
Binary XML format defined in annex D, section D.2.3 of the OSP specification. In the 
absence of any value for this parameter, the token contents shall be self identifying 
or otherwise understood by appropriate parties, 
x-osp-token-version : a character string indicating the earliest revision of the OSP 

specification to which the token contents conform. In the absence of any value for 
this parameter, the token contents shall conform to version "2.1.1" of the OSP 
specification. 
Encoding considerations: OSP tokens are normally carried as binary data by the call 

signalling protocol. Call signalling protocols which cannot reliably transfer binary data 
may use alternate encodings such as base-64, in which case standard MIME content-encoding 
parameters may indicate the particular encoding. 
Security considerations: OSP tokens are intended to provide access control to resources of 
other administrative domains, and, as such, are inherently designed to address security 
concerns. For that reason, OSP tokens are digitally signed and, optionally, encrypted, as 
defined in the OSP specification. 
Interoperability considerations: The means and/or algorithms by which a receiving system 
determines whether or not an OSP token is valid are a local matter. However, at a 
minimum, receiving systems should verify the digital signature of the token, and they 
should ensure that any call details included in the token contents (e.g. called number, 
calling number, etc.) are appropriate for the contemplated call. 
Published specification: "Telecommunications and Internet Protocol Harmonization Over 
Networks (TIPHON) ; Open Settlement Protocol (OSP) for Inter-domain pricing, 
authorization, and usage exchange". Technical Specification 101 321. European 
Telecommunications Standards Institute. Version 2.1.1 
Applications which use this media type: IP telephony call signalling protocols that use MIME 

types to convey additional information during call setup. 
Additional information : 

Magic number (s) : none 
File extension (s) : none 
Macintosh File Type Code(s) : none 
Person & email address to contact for further information: Stephen Thomas, 

Stephen . thomasl? trans nexus . com 
Intended usage: COMMON 
Author/Change controller: European Telecommunications Standards Institute 

NOTE: A corresponding MIME type of osp-token may be registered with lANA in the future. 
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D.4 Sample Token 



30 82 


01 


Al 


SEQUENCE (len = 


417) 


06 09 






OBJECT IDENTIFIER = 1.2.840.113594.1.7.2 (id-signedData) 


AO 82 


01 


92 


EXPLICIT TAG [0] (len = 402) 


30 82 


01 


8E 


SEQUENCE (len = 398) 


02 01 


03 




INTEGER = 3 (version) 


31 OE 






SET 


(len = 14) 


30 OC 








SEQUENCE (len = 12) 


06 08 








OBJECT IDENTIFER = 1.2.840.113594.2.5 (md5) 


05 00 








NULL 


30 82 


00 


B3 


SEQUENCE (len = 179) 


06 06 








OBJECT IDENTIFIER = 0.4.0.1321.2.3 (osp-token-contents-bxml) 


AO 82 


00 


AB 




EXPLICIT TAG [0] (len = 171) 


04 82 


00 


A7 




OCTET STRING (len = 167) 


02 01 


03 


00 




token contents 


31 82 


00 


CO 


SET 


(len = 192) 


30 82 


00 


EC 




SEQUENCE (len = 188) 


02 01 


03 






INTEGER = 3 (version) 


AO 16 








EXPLICIT TAG [0] 


04 14 








OCTET STRING (len = 20) 

SHA-1 hash of signer's public key information 


30 OC 








SEQUENCE (len = 12) 


06 08 








OBJECT IDENTIFIER = 1.2.840.113594.2.5 (md5) 


05 00 








NULL 


30 OD 








SEQUENCE (len = 13) 


06 09 








OBJECT IDENTIFIER = 1.2.840.113594.1.1.1 (rsa) 


05 00 








NULL 


04 82 


00 


80 




OCTET STRING (len = 128) 
signature 
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Annex E (informative): 
Example IVIessages 



This annex provides complete example messages for several information exchanges. The messages included are full and 
complete, but subject to the following modifications for readability: 

the content-type field of the HTTP header is shown as several lines. In actual implementations, that field will be 
constrained to a single line in conformance with HTTP specifications; 

extra whitespace is included within the example XML documents. In actual implementations, this whitespace 
shall be removed before the digital signature is generated (according to the constraints of clause 7), and is not 
likely to be included in the actual transferred data; 

the digital signatures within the example messages do not represent the actual digital signature for the example 
content. Actual signatures would likely result in unprintable characters. 



E.1 Pricing Exchange 



The following two messages convey pricing information between two parties. The first message provides three separate 
price indications. Taken together, the three indications represent prices for basic Internet telephony service (thus the 
empty <Service> element) of '/i DM/minute to Berlin (country code 49, national destination code 30) 1 DM/minute 
elsewhere in Germany (country code 49), and 2 DM/minute elsewhere in the world. In all three cases no constraints are 
placed on the calling party (thus the empty <SourceInf o> elements). 

POST scripts/settlements HTTP/1.0 
content-type: multipart /signed; 

protocol="application/pkcs7-signature"; 

micalg=shal; 

boundary=bar 
content-length: 1968 

— bar 

Content-Type: text/plain 

Content-Length: 1647 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<PricingIndication component I d="b"> 
<Timestamp> 

1998-04-20T19:03:00Z 
</Timestamp> 

<SourceInfo type="el64pref ix"/> 
<DestinationInfo type="el64pref ix"/> 
<Currency> 

DEM 
</Currency> 
<Amount> 

2 
< /Amount > 
<Increment> 

60 
</lncrement> 
<Unit> 

s 
</Unit> 
<Service/> 
<ValidAfter/> 
<ValidUntil/> 
</Pricinglndication> 
<PricingIndication componentId="c"> 
<Timestamp> 

1998-04-20T19:03:02Z 
</Timestamp> 

<SourceInfo type="el64pref ix"/> 
<DestinationInfo type="el64pref ix"> 

49 



ETSI 



47 ETSI TS 101 321 V2.1 .1 (2000-08) 



</DestinationInfo> 
<Currency> 

DEM 
</Currency> 
<Amount> 

1 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<Service/> 
<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 
<PricingIndication component I d="d"> 
<Timestamp> 

1998-04-20T19:03:05Z 
</Timestamp> 

< Source Info type="el64pref ix"/> 
<DestinationInfo type="el64pref ix"> 

4930 
</DestinationInfo> 
<Currency> 

DEM 
</Currency> 
<Amount> 

0.5 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<Service/> 
<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 
</Message> 

— bar 

Content-Type : application/pkcs7-signature 

Content-Length: 191 

GhyHhHUujhJhjH77n8HHGTrfvbnj75 6tbB9HG4VQpfyF4 67GhIGfHfYT64VQpfyF4 67GhIGfHfYT6jH77n8HH 
GghyHhHUujhh756tbB9HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfHfYT6ghyHhHUujpfyF4 
7GhIGfHfYT64VQbnj756 

— bar — 

The following example shows a confirmation in reply to the above message. In the confirmation, all pricing information 
is accepted. 

HTTP/ 1.0 200 OK 

content-type: multipart/signed; 

protocol="application/pkcs7-signature"; 

micalg=shal; 

boundary=bar 
content-length: 1401 

— bar 

Content-Type: text/plain 

Content-Length: 1080 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<PricingConf irmation component I d="b"> 
<Timestamp> 

1998-04-20T19:04:00Z 
</Timestamp> 
<Status> 
<Code> 

201 
</Code> 
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<Description> 

new pricing created 
</Description> 
</Status> 
</PricingConf irmation> 
<PricingConf irmation componentId="c"> 
<Timestamp> 

1998-04-20T19:04:22Z 
</Timestamp> 
<Status> 

<Code> 

210 
</Code> 
<Description> 

revised pricing accepted 
</Description> 
</Status> 
</PricingConf irmation> 
<PricingConf irmation component I d="d"> 
<Timestamp> 

1998-04-20T19:04:45Z 
</Timestamp> 
<Status> 

<Code> 

210 
</Code> 
<Description> 

revised pricing accepted 
</Description> 
</Status> 
</PricingConf irmation> 
</Message> 

— bar 

Content-Type : application/pkcs7-signature 

Content-Length: 191 

GhyHhHUujhJhjH77n8HHGTrfvbnj75 6tbB9HG4VQpfyF4 67GhIGfHfYT64VQpfyF4 67GhIGfHfYT6j 
H77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfHfYT 
6ghyHhHUujpfyF47GhIGfHfYT64VQbnj75 6 

— bar— 



E.2 Authorization Exchange 



The authorization exchange shows one party requesting and receiving authorization to access another party's devices. In 
particular, the requestor wishes to complete a phone call in which the calling party is at +81 45 881 1202 and the called 
party is at +47 66 84 13 60. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length: 600 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<AuthorizationRequest component I d="b"> 
<Timestamp> 

1998-04-24T17:03:00Z 
</Timestamp> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
<SourceInfo type="el64"> 

81458811202 
</SourceInfo> 
<DestinationInf o type="el64"> 

4766841360 
</DestinationInfo> 
<Service/> 
<MaximumDestinations> 

5 
</MaximumDestinations> 
< /Author izationRe quest > 
</Message> 
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The reply to this request returns two separate authorizations, each representing a different peer system that is capable of 
completing the call. For each destination, the response authorizes up to 24 hours of service for the call. 

HTTP/ 1.0 200 OK 
content-type: text/plain 
Content-Length: 1799 

<?xml version= ' 1 . ' ?> 

<Message messagelcl="a" random="1234"> 

<AuthorizationResponse component I d="b"> 
<Timestamp> 

1998-04-24T17:03:01Z 
</Timestamp> 
<Status> 

<Code> 

200 
</Code> 
<Description> 

success 
</Description> 
</Status> 
<TransactionId> 

67890987 
</TransactionId> 
<Destination> 

<DestinationSignalAddress> 

[172.16.1.2] :112 
</DestinationSignalAddress> 
<Token encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHOujhJh75 6t 
HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfH 
6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj 
</Token> 
<ValidAfter> 

1998-04-24T17:01:01Z 
</ValidAfter> 
<ValidUntil> 

1998-04-24T17:ll:01Z 
</ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 

24 
</Amount> 
<Increment> 

3600 
</Increment> 
<Unit> 

s 
</Unit> 
</UsageDetail> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
</Destination> 
<Destination> 

<DestinationSignalAddress> 

[10.0.1.2] :112 
</DestinationSignalAddress> 
<Token encoding="base64 "> 

F4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6tYT64VQpfy 
8HHGTrfvliJhjH77 6tbB9HG4VQbnj75 6HGTrfvbnjn7GhIGfH 
ujpfyF47GhIGfHfYT64VQbnj6ghyHliHU 
</Token> 
<ValidAfter> 

1998-04-24T17:01:02Z 
</ValidAfter> 
<ValidUntil> 

1998-04-24T17:ll:02Z 
</ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 

24 
< /Amount > 
<Increment> 
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3600 
</Increment> 
<Unit> 

s 
</Unit> 
</UsageDetail> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
</Destination> 
< /Author izationResponse> 
</Message> 



E.3 Usage Exchange 



The final examples demonstrate the exchange of usage information. The first message reports a call duration of 
10 minutes. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length; 926 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 
<Usage Indication component I d="b"> 
<Timestamp> 

1998-04-24T22:03:00Z 
</Timestamp> 
<Role> 

source 
</Role> 
<TransactionId> 

67890987 
</TransactionId> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
<SourceInfo type="el64"> 

81458811202 
</SourceInfo> 
<SourceAlternate type="subscriber"> 

8912342718473772 
</SourceAlternate> 
<DestinationInf o type="el64"> 

4766841360 
</DestinationInfo> 
<DestinationAlternate type="transport "> 

[10.0.1.2] :112 
</DestinationAlternate> 
<UsageDetail> 
<Service/> 
<Amount> 

10 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<StartTime critical="f alse"> 

1999-05-02T19:03:00Z 
</StartTime> 
<EndTime critical="false"> 

1999-05-02T19:13:00Z 
</EndTime> 

<TerminationCause critical="false"> 
<TCCode> 
1016 
</TCCode> 
<Description> 

normal call clearing 
</Description> 
</TerminationCause> 
</UsageDetail> 
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</UsageIndication> 
</Message> 

To complete the exchange, the server responds with a UsageConfirmation. 

HTTP/1.0 200 OK 
content-type: text/plain 
Content-Length: 404 

<?xml version= ' 1 . ' ?> 

<Message messagelcl="a" ranclom="1234"> 
<UsageConf irmation component I d="b"> 
<Timestamp> 

1998-04-24T22:44:00Z 
</Timestamp> 
<Status> 

<Code> 

201 
</Code> 
<Description> 

new usage information created 
</Description> 
</Status> 
</UsageConf irmation> 
</Message> 



E.4 Subscriber Authentication Exchange 

The following two messages show the authentication of an individual subscriber. The first message requests 
authentication for ISO/IEC 7812-1 [30] (calling card or charge card) number 5100123456789012. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length: 336 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<SubscriberAuthenticationRequest component I d="b"> 
<Timestamp> 

1998-04-24T17:03:00Z 
</Timestamp> 
<SourceInfo type="iso7812"> 

5100123456789012 
</SourceInfo> 
</SubscriberAuthenticationRequest> 
</Message> 

The following response indicates a successful authentication. 

HTTP/ 1.0 200 OK 
content-type: text/plain 
Content-Length: 427 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<SubscriberAuthenticationResponse component I d="b"> 
<Timestamp> 

1998-04-24T17:03:01Z 
</Timestamp> 
<Status> 
<Code> 

200 
</Code> 
<Description> 

success 
</Description> 
</Status> 
</ Subs criberAuthenti cat ionResponse> 
</Message> 
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E.5 Capabilities Exchange 



This section illustrates the exchange of capabilities between client and server. In the first message, the client identifies 
its manufacturer's serial number, indicates that it can support OSP version 2.1.1, that it expects to send 
AuthorizationRequest and Usagelndication messages, and that it has a total of 64 Kbit/s of capacity available. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length: 779 

<?xml version= ' 1 . ' ?> 

<Message messagelcl="a" ranclom="1234"> 

<CapabilitiesInclication componentId="b" critical = "f alse"> 
<DeviceInfo type="serialnumber" critical="f alse"> 

12345678 
</DeviceInfo> 
<OSPVersion critical="f alse"> 

2.1.1 
</OSPVersion> 
<OSPCapability critical="f alse"> 

AuthorizationRequest 
</OSPCapability> 
<OSPCapability critical="f alse"> 

Usagelndication 
</OSPCapability> 
<Resources critical="false"> 

<DataRate critical="false"> 

<Bandwidth critical="f alse"> 

64000 
</Bandwidth> 
</DataRate> 
</Resources> 
</CapabilitiesIndication> 
</Message> 

The server replies with a confirmation that it can support OSP version 2.1.1, and it provides URLs for the client to use 
for OSP services. Note that the server includes an HTTP "Expires" header, indicating that the client should reconfirm its 
capabilities prior to 1 December 2000. 

HTTP/ 1.0 200 OK 

Expires: Thu, 01 Dec 2000 16:00:00 GMT 
content-type: text/plain 
Content-Length: 1542 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<CapabilitiesConf irmation componentId="b" critical="f alse"> 
<Timestamp> 

1998-04-24T22:44:OOZ 
</Timestamp> 
<Status> 
<Code> 

200 
</Code> 
</Status> 
<OSPVersion critical="f alse"> 

2.1.1 
</OSPVersion> 
<OSPService critical="false"> 

<OSPCapability critical="f alse"> 

AuthorizationRequest 
</OSPCapability> 
<OSPServiceURL cr it ical=" false "> 

http : // server 1 . domain . com/osp/authreq 
</OSPServiceURL> 
<OSPServiceURL cr it ical=" false "> 

http : //server 2 . domain . com/osp/authreq 
</OSPServiceURL> 
<OSPSignatureRequired critical=" false "> 

false 
</OSPSignatureRequired> 
</OSPService> 
<OSPService critical="f alse"> 

<OSPCapability critical="f alse"> 
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Usage Indication 
</OSPCapability> 
<OSPServiceURL critical="false"> 

http : // server 1 . domain . com/osp/usageind 
</OSPServiceURL> 
<OSPServiceURL cr it ical=" false "> 

http : //server 2 . domain . com/osp/usageind 
</OSPServiceURL> 
<OSPSignatureRequired critical=" false "> 

false 
</OSPSignatureRequired> 
</OSPService> 
</CapabilitiesConf irmation> 
</Message> 
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Annex F (informative): 
Billing Format Conversion 



A wide variety of billing formats are currently in use within telecommunications and data networking systems. One of 
the advantages of using Extensible Markup Language within the present document is that it allows extremely easy 
conversion of usage information to and from other formats. As a demonstration of that flexibility, this annex includes 
example software to covert from <UsageIndication> components to a proprietary call detail record format of one 
particular, commercially-available system — the VocalTec Internet Telephony Gateway version 3.1. The software is 
written in Java, and relies on an XML parser available from Microsoft at http://www.microsoft.com/xml. Both the 
gateway and XML parser are selected solely to demonstrate the ease of the format conversion; this annex does not 
imply the suitability or fitness of either product for any purpose. 

import com.ms . xml . parser . *; 

import com. ms . xml . om. Document ; 

import com. ms . xml . om. Element ; 

import com.ms . xml . util . XMLOutputStream; 

import com.ms . xml . util . Name; 

import com.ms . xml . om. ElementE numeration; 

import com.ms . xml . om.Elementlmpl; 

import Java . util . Enumeration; 

import java.io.*; 

import Java . io . PrintStream; 

import java.net.*; 

import Java. util.*; 

import com.ms . xml . util . Name; 

import com.ms . xml . om. Element Factory; 

class CDR 
{ 

public static void main (String args [ ] ) 
1 

// "fix" the version to 2 digits to workaround a bug in the XML parser 

Properties props = new Properties (); 

props = System. getProperties (); 

props. put (" Java. version", "1.1"); 

System. setProperties (props); 

parseArgs (args); 

if (fileName == null) 

printUsage (System. out ) ; 
else 
{ 

URL url = createURL (fileName) ; 

Document d = null; 

try 

{ 

d = new Document ( ) ; 

d. setCaselnsensitive (true); 

d. setLoadExternal (true); 

d. load (url) ; 
} 

catch (ParseException e) 
{ 

System. out .println (e); 
} 

if (d != null) 
{ 

loadValues (d) ; 

// type 

cdr = pad ("Voice", 10); 

// date 

cdr += pad ( ( (timestamp == null) ? " — " : 

timestamp . substring (5, 10) + "-" + timestamp . substring (2, 4)), 10); 
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// time 

cdr += pad ( ( (timestamp == null) ? " — " : 
timestamp. substring (11, 19)), 10); 

// duration 

cdr += pad (((unit != null && unit. equals ("s") && amount != null && 

increment != null) ? "" + Integer .parseint (amount) * 

Integer .parseint (increment) : " — "), 10); 

// username 

cdr += pad ("User Name", 30); 

// dialed number 

cdr += pad (destinationinf o, 30) ; 

// line 

cdr += pad ("1", 10) ; 

// remote name 

cdr += pad ("Remote Name", 30); 

// disconnect reason 

cdr += pad ("Disconnect Reason", 40); 

// remote IP 

cdr += pad ("000.000.000.000", 20); 

// remote code 

cdr += pad ("0000", 15) ; 

// call type 

cdr += pad ((role != null SS role. equals ("destination") ? "IPVOD" : "OPVOD"), 15), 

// user ID 

cdr += pad ("000000", 10); 

// fax pages 

cdr += pad ("", 13) ; 

// remote fax ID 
cdr += pad ("", 25); 

// local fax ref 
cdr += pad ("", 16) ; 

// remote fax ref 
cdr += pad ("", 16) ; 

// fax transfer mode 
cdr += pad ("", 18) ; 

// E.164 number 

cdr += pad (destinationinfo, 24); 

System. out .println (cdr); 
} 
} 

System. exit (0) ; 
} 

static void printUsage (PrintStream o) 
{ 

o. println ("Usage; Java CDR filename"); 

o . println ( ) ; 
} 

static void parseArgs (String args [ ] ) 
{ 

if (args . length> 0) 

fileName = args [0]; 
} 

static String pad (String s, int num) 
{ 

String str; 

int len; 

if (s == null) 
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str = " 
len = 4; 



else 



str = s; 

len = s . length ( ) , 

if (len> num) 

{ 

str = " — "; 

len = 4; 



for (int i = len; i <num; i++) 

str += " "; 
return str; 



} 



static URL createURL (String fileName) 

// Microsoft method 

{ 

URL url = null; 

try 

{ 

url = new URL (fileName) ; 
} 

catch (Malf ormedURLException ex) 
{ 

File f = new File (fileName); 

try 

{ 

String path = f . getAbsolutePath ( ) ; 

String fs = System. getProperty ( "file . separator ") ; 

if (fs.lengthO == 1) 

{ 

char Sep = f s . charAt (0); 
if (sep != '/') 

path = path. replace (sep, '/'); 
if (path. CharAt (0) !='/') 
path = ' / ' + path; 
} 

path = "file://" + path; 
url = new URL (path) ; 
} 

catch (Malf ormedURLException e) 
{ 

System. out . println ("Cannot create url for: " + fileName), 
System. exit (0) ; 



return url; 



static void loadValues (Element e) 
{ 

String attName = " — NULL — "; 

String tagName; 

if (e.getTagName () != null) 
1 

attName = e.getText (); 

tagName = e.getTagName () .toString (); 

if (tagName. equals ( "TIMESTAMP") ) 
timestamp = attName; 

if (tagName. equals ( "DESTINATIONINFO" ) ) 
destinationinf o = attName; 

if (tagName. equals ("AMOUNT")) 
amount = attName; 

if (tagName. equals ("INCREMENT")) 
increment = attName; 

if (tagName. equals ("UNIT")) 
unit = attName; 
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if (tagName . equals ("ROLE")) 
role = attName; 
} 

for (ElementEnumeration en = new ElementEnumeration (e) ; en .hasMoreElements {) ; ) 
{ 

Element child = (Element) en .nextElement () ; 

loadValues (child) ; 



static String fileName, timestamp, destinationinf o, amount, increment, unit, role, cdr; 
} 
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Annex G (informative): 
XIVIL Overview 



As an aid to those readers unfamiliar with Extensible Markup Language, this annex offers a brief overview of the 
syntax of XML documents. Key components of XML structure are document definitions, element declarations, and 
attribute declarations. 

NOTE: This annex is neither authoritative nor complete. A formal definition of XML may be found in [3]. 



G.1 Document Definition 

XML documents are defined using the following format: 

<!DOCTYPE DocumentName [DocumentStructureDef Inltion] > 

DocumentName is the name of the XML document, and DocumentStructureDef nition is a series of element, 
attribute, and entity declarations. Those declarations are described below. An example document definition is: 



I 'c') 'a' #REQUIRED> 



<!DOCTYPE Z [ 






<! ELEMENT 


Y 


(X, W)> 


<!ATTLIST 


Y 


('a' 1 'b 


<! ELEMENT 


X 


CDATA> 


<! ELEMENT 


W 


CDATA> 



]> 



G.2 Element Declaration 

XML elements are declared using the following format: 

<!ELEMENT ElementName (ElementContents) > 

ElementName, as expected, is the name of the element being declared, while ElementContents specifies the 
permissible contents of the element. Elements may include child elements, in which case the ElementContents part 
defines their order and number within the parent element, and element may include character data. 

Child elements within the ElementContent s part of a declaration may be designated as a sequence of child 
elements or a choice of child elements. The comma (,) separates individual child elements in a sequence, while the 
vertical bar (I) separates child elements in a choice. For example, < ! ELEMENT Y (X, W) > indicates that element Y 
consists of a child element X followed by a child element W. Similarly, < ! ELEMENT Z (X | W) > indicates that 
element Z consists of either a child element X or a child element W. 

The element declaration indicates the number of child elements permitted by a character following the child element's 
name. No character indicates that exactly one child element, a question mark (?) indicates zero or one child element, an 
asterisk (*) indicates zero or more child elements, and a plus (+) indicates one or more child elements. 

For example: 

<!ELEMENT X (A, B?, C*, D+)> 

defines element X as consisting of: 

Table G.1 



child 
element 


element 
declaration 


meaning 


A 


(none) 


exactly one child element 


B 


? 


zero or one child element 


C 


* 


zero or more child elements 


D 


+ 


one or more child elements 
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G.3 Attribute Declaration 

XML attributes are associated with elements; they are declared using the format: 

<!ATTLIST ElementName AttributeNamel DeclaredValuel Def aultValuel 
AttributeName2 DeclaredValue2 Def aultValue2 

AttributeNameN DeclaredValueN Def aultValueN> 

ElementName identifies the XML element with which the attributes may be used. AttributeNamel, 
AttributeName2, ... are the names of the attributes defined for the element. Each attribute has either a list of 
permissible values or a data type, which the above construction labels DeclaredValue. The final part of each 
attribute's declaration is Def aultValue, which indicates the default value for the attribute, as well as constraints on 
its presence. 

Explicit, permissible values for attributes are separated by the vertical bar (I). So that, for example the Boolean 
attribute for element X may be declared as: 

<!ATTLIST X Boolean (true 1 false) > 

NOTE 1 : No default value is specified in the above declaration. If a default value is specified, then the 
DefaultValue section may appear as one of: 

#REQUIRED: some explicit value for the attribute shall be included each time the attribute is used; 

# IMPLIED: if no explicit value for the attribute is used, then the application may infer a default value; 

' value ' if no explicit value for the attribute is used, then the attribute should be assumed to have the 
value 'value'; 

#FIXED ' value ' : the attribute shall have, and can only have, the value 'value'. 

EXAMPLE: If the Boolean attribute should be assumed to be true unless otherwise, explicitly indicated, the 
following declaration would apply. 

<!ATTLIST X Boolean (true 1 false) 'true'> 

NOTE 2: No quotation marks are used in the DeclaredValue part, while the DefaultValue part does 
enclose the value in quotations. 
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Annex H (informative): 

Binary XIVIL Content Format for OSP 

In some implementations, minimizing the size of protocol messages is a critical requirement. The Binary XML Content 
Format [29], developed by the Wireless Application Protocol (WAP) Forum) provides a standard method for 
compressing XML content, and it can be directly applied to OSP messages. This annex provides the information 
necessary to use Binary XML Content Format in an interoperable manner by defining global extension tokens for OSP. 
It also includes an example message to illustrate the application of the format. 
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H.1 Global Extension Tokens 

The following tables define the global extension tokens for OSP. 



Table H.1 : Global extension tokens for OSP tags 

CODE PAGE TOKEN TAG NAME 

05 AlmostOutOfResources 

06 Amount 

07 AuthorityURL 

08 AuthorizationConfirmation 

09 Authorizationlndication 

OA AuthorizationRequest 

OB AuthorizationResponse 

OC Bandwidth 

CD Callld 

OE Certificate 

OF CertificateChain 

10 Code 

1 1 Currency 

12 DataRate 

13 Description 

14 Destination 

15 DestinationAlternate 

16 Destinationlnfo 

17 DestinationSignalAddress 

18 Deviceld 

19 Devicelnfo 

1A Endlime 

1 B Fraction 

1C Increment 

ID Loss Received 

1 E LossSent 

IF MaximumDestinations 

20 Mean 

21 Message 

22 Minimum 

23 NumberOfCliannels 

24 OneWayDelay 

25 Pacl<ets 

26 ReauthorizationRequest 

27 ReauthorizationResponse 

28 Resources 

29 Role 

2A RoundTripDelay 

2B Samples 

2C Service 

2D SourceAlternate 

2E Sourcelnfo 

2F SourceSignalAddress 

30 Startlime 

31 Statistics 

32 Status 

33 TCCode 

34 TerminationCause 

35 Timestamp 

36 Token 
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CODE PAGE 


TOKEN 


TAG NAME 





37 


Tokenlnfo 





38 


Transaction Id 





39 


Unit 





3A 


UsageConfirmation 





3B 


UsageDetail 





3C 


Usagelndication 





3D 


ValidAfter 





3E 


ValidUntil 





3F 


Variance 




05 


CapabilitiesConfirmation 




06 


Capabilitieslndication 




07 


OSPCapability 




08 


OSPService 




09 


OSPServiceURL 




OA 


OSPSignatureRequired 




OB 


OSPVersion 




OC 


PricingConfirmation 




OD 


Pricinglndication 




OE 


SubscriberAuthenticationlnfo 




OF 


SubscriberAuthenticationRequest 




10 


SubscriberAuthenticationResponse 



Table H.2: Global extension tokens for OSP attributes 

TOKEN ATTRIBUTE 

05 componentid 

06 critical false 

07 critical true 

08 encoding base64 

09 encoding cdata 
OA messageld 

OB random 

OC type abbreviated 

OD type customerld 

OE type deviceld 

OF type el 64 

10 type e164prefix 

1 1 type email 

12 type epin 

1 3 type h323 

14 type international 

15 typeiso7812 

1 6 type national 

1 7 type network 

18 type pin 

19 type serialnumber 
1A type subscriber 

1 B type transport 

1 C type uri 
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H.2 Example Application 



This section illustrates the process of converting an OSP message to Binary XML Content Format. It uses the example 
AuthorizationRequest from annex E. 

H.2.1 Standard XML Format (505 bytes) 

<?xinl version= ' 1 . ' ?> 

<Message messageld="a" random="12 34 "> 

<AuthorizationRequest component I d="b"> 
<Timestainp> 

1998-04-24T17:03:00Z 
</Tiinestamp> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6 jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
<SourceInfo type="el64"> 

81458811202 
</SourceInfo> 
<DestinationInf o type="el64"> 

4766841360 
</DestinationInfo> 
<Service/> 
<MaximumDestinations> 

5 
</MaxiinuinDestinations> 
</AuthorizationRequest> 
</Message> 



H.2.2 Binary XML Content Format (1 60 bytes) 



02 


01 


03 00 


El 


OA 


03 'a' 00 OB 03 '1234' 00 




CA 


05 03 'b' 00 
75 03 '1998-04-24T17:03:00Z' 00 01 
CD 08 01 03 

' YT64VQpfyF467GhIGfHfYT6 jH77n8HHGghyHhHUujhJh756t ' 00 01 
EE OF 01 03 '81458811202'00 01 
D6 OF 01 03 '4766841360'00 01 
2C 
5F 03 '5'00 01 




01 




01 
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Annex I (normative): 

PICS proforma for OSP (TS 101 321) v2.1 .1 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the PICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed PICS. 



1.1 Guidance for completing the PICS proforma 



1.1.1 Purposes and structure 



The purpose of this PICS proforma is to provide a mechanism whereby a supplier of an implementation of the 
requirements defined in the present document may provide information about the implementation in a standardized 
manner. 

The PICS proforma is subdivided into subclauses for the following categories of information: 

guidance for completing the PICS proforma; 

identification of the implementation; 

identification of the protocol; 

global statement of conformance; 

roles; 

major capabilities; 

subsidiary capabilities; 

operations; 

arguments, results and errors; 

timers. 

1.1 .2 Abbreviations and conventions 

The PICS proforma contained in this annex is comprised of information in tabular form in accordance with the 
guidelines presented in ISO/IEC 9646-7 [26]. 

Item column 

The item column contains a number which identifies the item in the table. 

Item description column 

The item description column describes in free text each respective item (e.g. parameters, timers, etc.). It implicitly 
means "is <item description> supported by the implementation". 

Status column 

The following notations, defined in ISO/IEC 9646-7 [26], are used for the status column: 
m mandatory - the capability is required to be supported; 

o optional - the capability may be supported or not; 
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n/a not applicable - in the given context, it is impossible to use the capability; 

X prohibited (excluded) - there is a requirement not to use this capability in the given context; 

o.i qualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which 

identifies a unique group of related optional items and the logic of their selection which is defined 
immediately following the table; 

ci conditional - the requirement on the capability ("m", "o", "x" or "n/a") depends on the support of 

other optional or conditional items, "i" is an integer identifying a unique conditional status 
expression which is defined immediately following the table; 

i irrelevant (out-of-scope) - capability outside the scope of the reference specification. No answer is 

requested from the supplier. 

Reference column 

The reference column makes reference to ETSI TS 101 321, except where explicitly stated otherwise. 

Support column 

The support column shall be filled in by the supplier of the implementation. The following common notations, defined 
in ISO/IEC 9646-7 [26], are used for the support column: 

Y or y supported by the implementation; 

N or n not supported by the implementation; 

N/A, n/a or - no answer required (allowed only if the status is n/a, directly or after evaluation of a conditional 

status). 

If this PICS proforma is completed in order to describe a multiple-profile support in a system, it is necessary to be able 
to answer that a capability is supported for one profile and not supported for another. In that case, the supplier shall 
enter the unique reference to a conditional expression, preceded by "?" (e.g. ?3). This expression shall be given in the 
space for comments provided at the bottom of the table. It uses predicates defined in the SCS, each of which refers to a 
single profile and which takes the value TRUE if and only if that profile is to be used. 

EXAMPLE 1 : ?3 : IF prof 1 THEN Y ELSE N. 

It is also possible to provide a comment to an answer in the space provided at the bottom of the table. 

NOTE: As stated in ISO/IEC 9646-7 [26], support for a received PDU requires the ability to parse all valid 
parameters of that PDU. Supporting a PDU while having no ability to parse a valid parameter is non- 
conformant. Support for a parameter on a PDU means that the semantics of that parameter are supported. 

Values allowed column 

The values allowed column contains the type, the list, the range, or the length of values allowed. The following 
notations are used: 

range of values: <min value> .. <max value>: 

EXAMPLE 2: 5 .. 20; 

list of values: <valuel>, <value2>, , <valueN>: 

EXAMPLE 3: 2 ,4 ,6 ,8, 9; 
EXAMPLE 4: 'llOl'B, 'lOll'B, 'llll'B; 
EXAMPLE 5: 'OA'H, '34'H, '2F'H; 

list of named values: <namel>(<vall>), <name2>(<val2>), ...., <nameN>(<valN>: 
EXAMPLE 6: reject(l), accept(2); 

length: size (<min size> .. <max size>): 
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EXAMPLE 7: size (1 .. 8). 

Values supported column 

The values supported column shall be filled in by the supplier of the implementation. In this column, the values or the 
ranges of values supported by the implementation shall be indicated. 

References to items 

For each possible item answer (answer in the support column) within the PICS proforma a unique reference exists, 
used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", 
followed by the item number in the table. If there is more than one support column in a table, the columns are 
discriminated by letters (a, b, etc.), respectively. 

EXAMPLE 8: A. 5/4 is the reference to the answer of item 4 in table 5 of annex A. 

EXAMPLE 9: A.6/3b is the reference to the second answer (i.e. in the second support column) of item 3 in 
table 6 of annex A. 

Prerequisite line 

A prerequisite line takes the form: Prerequisite: <predicate>. 

A prerequisite line after a clause or table title indicates that the whole clause or the whole table is not required to be 
completed if the predicate is FALSE. 

1.1 .3 Instructions for completing the PICS proforma 

The supplier of the implementation shall complete the PICS proforma in each of the spaces provided. In particular, an 
explicit answer shall be entered, in each of the support or supported column boxes provided, using the notation 
described in subclause I.L2. 

If necessary, the supplier may provide additional comments in space at the bottom of the tables, or separately on sheets 
of paper. 

More detailed instructions are given at the beginning of the different subclauses of the PICS proforma. 



1.2 Identification of the implementation 

Identification of the Implementation Under Test (lUT) and the system in which it resides (the System Under Test 
(SUT)) should be filled in so as to provide as much detail as possible regarding version numbers and configuration 
options. 

The product supplier information and client information should both be filled in if they are different. 

A person who can answer queries regarding information supplied in the PICS should be named as the contact person. 



1.2.1 Date of the statement 
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1.2.2 Implementation Under Test (lUT) identification 

lUT name: 



lUT version: 

1.2.3 System Under Test (SUT) identification 

SUT name: 

Hardware configuration: 



Operating system: 

1.2.4 Product supplier 

Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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1.2.5 Client (if different from product supplier) 

Name: 
Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 



1.2.6 PICS contact person 

(A person to contact if there are any queries concerning the content of the PICS) 
Name: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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1.3 PICS 

1.3.1 Identification of the protocol 

The PICS proforma applies to the following standard: 

TS 101 321: "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Open 
Settlement Protocol (OSP) for Inter-Domain pricing, authorization, and usage exchange" (the present document). 

1.3.2 Global Statement of Conformance 

Are all mandatory capabilities implemented? (Yes/No). 

NOTE: Answering "No" to this question indicates non-conformance to the protocol specification. Non-supported 
mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is 
non-conforming, on pages attached to the PICS proforma. 

1.3.3 Roles 

Table 1.1 : Roles 



Item 


Role 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


OSP Client 




Ol 




2 


OSP Server 




o1 





ol : Support of at least one of these options is required. 



1.3.4 Major capabilities 



Table 1.2: Major capabilities 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


SSLv3 









2 


HTTPvLO 




m 




3 


MIME RFC 2045 




m 




4 


XMLvl.O 




m 




5 


HTTPvLI 
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1.3.5 Secure Socket Layer Security Capabilities 



Table 1.3: SSL Capabilities 



Prerequisite: Table 1.2/1 - If SSLv3 is supported then this table shall be completed 


Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


1 


SSL version 3 


5.1.1 


m 




2 


TLS version 1 


5.1.1 







3 


SSL/TLS client authentication 


5.13 







4 


SSL ciphering 


5.14 


C301 




5 


SSL Session Re-use 




C301 





C302: IF 1.3/1 
THENo 
ELSE n/a 



Table 1.4: SSL Cipher Suite support Capabilities 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


1 


SSL RSA WITH NULL SHA 


annex B 


m 




2 


SSL RSA EXPORT WITH DES40 CBC SHA 


annex B 







3 


SSL RSA WITH 3DES EDE CBC SHA 


annex B 








1.3.6 Hypertext Transfer Protocol Capabilities 



Table 1.5: TCP Port capabilities 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values allowed 


Values supported 


1 


TCP port 


5.2.3 


C701 




443 




2 


TCP port 


5.2.3 


C702 




80 





C701: IF 1.2/1 
THENm 
ELSE n/a 

C702: IF NOT 1.2/1 
THENm 
ELSE n/a 



Table 1.6: HTTP method capability 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values allowed 


Values supported 


1 


Client messages as POST 


5.2.4 


m 








2 


Server messages as response 


5.2.4 


m 








Table 1.7: HTTP URI Support 


Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values allowed 


Values supported 


1 


Uniform Resource Identifier 


5.2.5 


m 
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Table 1.8: HTTPvl.O POST Header Capabilities 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values allowed 


Values supported 


1 


request-line 


5.2.6 


m 








2 


authorization 


HTTP1.0 10.2 











3 


from 


HTTP1.0 10.8 











4 


if-modified-since 


HTTP1.0 10.9 











5 


referer 


HTTP1.0 10.13 











6 


user-agent 


HTTP1.0 10.15 











7 


allow 


HTTP1. 10.1 











8 


content-encoding 


HTTP1 .0 10.3 











9 


content-length 


HTTP1. 10.4 











10 


content-type 


HTTP1.0 10.5 











11 


expires 


HTTP1.0 10.7 











12 


last-modified 


HTTP1.0 10.10 












Table 1.9: HTTPvl.O Response Header Capabilities 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values allowed 


Values supported 


1 


status-line 


5.2.6 


m 








2 


location 


HTTP1.0 10.il 











3 


server 


HTTP1.0 10.14 











4 


www-authenticate 


HTTP1.0 10.16 











5 


allow 


HTTP1. 10.1 











6 


content-encoding 


HTTP1 .0 10.3 











7 


content-length 


HTTP1 .0 10.4 











8 


content-type 


HTTP1.0 10.5 











9 


expires 


HTTP1.0 10.7 











10 


last-modified 


HTTP1.0 10.10 












Table 1.10: HTTPvl.O Status code support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values allowed 


Values supported 


1 


200 OK 


HTTP 1 .0 9.2 


m 








2 


201 Created 


HTTP 1 .0 9.2 











3 


202 Accepted 


HTTP 1 .0 9.2 











4 


204 No Content 


HTTP 1 .0 9.2 











5 


300 Multiple Choices 


HTTP 1 .0 9.3 











6 


301 Moved Permanently 


HTTP 1 .0 9.3 











7 


302 Moved Temporarily 


HTTP 1 .0 9.3 











8 


304 Not Modified 


HTTP 1 .0 9.3 











9 


400 Bad Request 


HTTP 1 .0 9.4 











10 


401 Unauthorized 


HTTP 1 .0 9.4 











11 


403 Forbidden 


HTTP 1 .0 9.4 











12 


404 Not Found 


HTTP 1 .0 9.4 











13 


500 Internal Server Error 


HTTP 1.0 9.5 











14 


501 Not Implemented 


HTTP 1 .0 9.5 











15 


502 Bad Gateway 


HTTP 1 .0 9.5 











16 


503 Service Unavailable 


HTTP 1 .0 9.5 
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1.3.7 Multipurpose Internet Mail Extensions Capabilities 



Table 1.11 : MIME primary message content capabilities 



Prerequisite: Table 1.2/3 - MIME is supported 


Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


1 


Multipart/signed 


5.2.7 







2 


Text/plain 


6.1.1.1 








Table 1.12: S/MIME signature capabilities 



Prerequisite: Table 1.2/3 - MIME is supported 


Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


S/MIME version 2 


5.2.7 


CI 201 




2 


Canonical Form 


7.1 


CI 201 




3 


Binary transfer encoding 


7.3 


C1201 





C1201: 



IF 1. 11/1 
THENm 
ELSE n/a 



■ If multipart/signed primary message content of MIME is supported 

■ then mandatory, else not applicable 



Table 1.13: S/MIME Signature algorithm capabilities 



Prerequisite: Table 1.2/3 - MIME is supported 


Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


Md2WithRSAEncryption 


S/MIME A.4 


C1301 




2 


Md5WithRSAEncryption 


S/MIME A.4 


C1301 




3 


Sha-IWithRSAEncryption 


S/MIME A.4 


C1301 





C1301: 



IF 1. 11/1 
THENo 
ELSE n/a 



■ If multipart/signed primary message content of MIME is supported 

■ then optional, else not applicable 



Table 1.14: MIME XML Transfer Capabilities 



Prerequisite: Table 1.2/3 - MIME is supported 


Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


Binary transfer encoding 


6.1.1.3 


m 





1.3.8 Extensible Markup Language Capabilities 



Table 1.15: XML Character Coding Support 



Prerequisite: Table 1.2/4 - XML is supported 


Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


UTF-8 


6.1.2.3 


m 








2 


UTF-16 


6.1.2.3 


m 








3 


other(s) 


6.1.2.3 







note 1 




4 


well-formed 


6.1.2.2 


m 








NOTE 1 : Permissible character encodings defined by ISO/IEC 1 0646 [27] 
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1.3.9 Root Message Capabilities 

Table 1.16: Root Message Capabilities 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Message as root entity 


6.1.3.1 


m 








2 


Maximum components 
sent per client message 


6.1.3 


C1601 




1 .. 




3 


Maximum components 
recognized per client 
message 


6.1.3 


CI 602 




1 .. 




4 


Equal components in 
server messages as 
received in client 
messages 


6.1.3 


CI 602 








5 


Random attribute 


6.1.3.2 


m 








6 


Identifier attribute 


6.1.3.3 


m 









C1601: 



C1802: 



IF 1. 1/1 


—Client role 


THENm 




ELSE n/a 




IF 1. 1/2 


—Server role 


THENm 




ELSE n/a 





Table 1.17: Random attribute Capabilities 



Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Random attribute present 
in messages 


6.1.3.2 


m 








2 


Random value statistically 
valid 


6.1.3.2 


m 








Table 1.18: Identifier attribute Capabilities 


Item 


Capability 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Identifier present in client 
messages 


6.13.3 


C1801 








2 


Identifier unique 


6.1.3.3 


C1801 




1 .. 




3 


Identifier returned in 
server messages 


6.1.3.3 


CI 802 




1 .. 




4 


Identifier associates 
server messages with 
client request/indication 


6.1.4.4 


CI 802 









C1801: 



C1602: 



IF L 1/1 


—Client role 


THENm 




ELSE n/a 




IF L 1/2 


—Server role 


THENm 




ELSE n/a 
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1.3.10 Message support 



It is mandatory to support the encoding and decoding of messages used by OSP. 

Table 1.19: PDU en/decoding 



Item 


Description 


Reference 


Status 


Support 


1 


XML message encoding 


6.2 


m 




2 


XML message decoding 


6.2 


m 





Table 1.20: Message support 



Item 


Description 


Reference 


Status 


Support 


1 


Pricinglndication 


6.2.1 







2 


PricingConfirmation 


6.2.2 







3 


AuthorizationRequest 


6.2.3 







4 


AuthorizationResponse 


6.2.4 







5 


Authorizationlndication 


6.2.5 







6 


AuthorizationConfirmation 


6.2.6 







7 


Usagelndication 


6.2.7 







8 


UsageConfirmation 


6.2.8 







9 


ReauthorizationRequest 


6.2.9 







10 


ReauthorizationResponse 


6.2.10 







11 


SubscriberAuthenticationRequest 


6.2.11 







12 


SubscriberAuthenticationResponse 


6.2.12 







13 


Capabilitieslndication 


6.2.13 







14 


CapabilitiesConfirmation 


6.2.14 








Table 1.21 : Pricinglndication Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


Timestamp 


6.3.19 


m 




2 


Sourcelnfo 


6.3.16 


m 




3 


Destinationlnfo 


6.3.9 


m 




4 


Currency 


6.3.5 


m 




5 


Amount 


6.3.1 


m 




6 


Increment 


6.3.11 


m 




7 


Unit 


6.3.22 


m 




8 


Service 


6.3.14 


m 




9 


ValidAfter 


6.3.24 


m 




10 


ValidUntil 


6.3.25 


m 





Table 1.22: PricingConfirmation Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


Timestamp 


6.3.19 


m 




2 


Status 


6.3.18 


m 
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Table 1.23: AuthorizationRequest Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Callld 


6.3.3 


m 








3 


Sourcelnfo 


6.3.16 


m 








4 


SourceAlternate 


6.3.15 











5 


Destinationlnfo 


6.3.9 


m 








6 


DestinationAlternate 


6.3.8 











7 


Service 


6.3.14 


m 








8 


MaximumDestinations 


6.3.12 


m 








9 


Token 


6.3.20 











10 


SubscriberAuthenticationlnfo 


6.3.37 












Table 1.24: AuthorizationResponse Support 



Item 


Information element 


Reference 


Status 


Support 

Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Status 


6.3.18 


m 








3 


Transaction Id 


6.3.21 


m 








4 


Destination 


6.3.7 











5 


Tol<en 


6.3.20 












Table 1.25: Authorizationlndication Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Role 


6.3.13 


m 








3 


Callld 


6.3.3 


m 








4 


Sourcelnfo 


6.3.16 


m 








5 


SourceAlternate 


6.3.15 











6 


Destinationlnfo 


6.3.9 


m 








7 


DestinationAlternate 


6.3.8 











8 


Service 


6.3.14 


m 








9 


Token 


6.3.20 












Table 1.26: AuthorizationConf Irmatlon Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


Timestamp 


6.3.19 


m 




2 


Status 


6.3.18 


m 




3 


ValidAfter 


6.3.24 


m 




4 


ValidUntil 


6.3.25 


m 
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Table 1.27: Usagelndication Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Role 


6.3.13 


m 








3 


Transaction Id 


6.3.21 


m 








4 


Callld 


6.3.3 


m 








5 


Sourcelnfo 


6.3.16 


m 








6 


SourceAlternate 


6.3.15 











7 


Destinationlnfo 


6.3.9 


m 








8 


DestinationAlternate 


6.3.8 











9 


UsageDetail 


6.3.23 












Table 1.28: UsageConf irmation Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


1 


Timestamp 


6.3.19 


m 




2 


Status 


6.3.18 


m 





Table 1.29: ReauthorizationRequest Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Role 


6.3.13 


m 








3 


Callld 


6.3.3 


m 








4 


Sourcelnfo 


6.3.16 











5 


SourceAlternate 


6.3.15 











6 


Destinationlnfo 


6.3.9 











7 


DestinationAlternate 


6.3.8 











8 


Transactionid 


6.3.21 


m 








9 


UsageDetail 


6.3.23 











10 


Token 


6.3.20 












Table 1.30: ReauthorizationResponse Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Status 


6.3.18 


m 








3 


Transactionid 


6.3.21 


m 








4 


Destination 


6.3.7 











5 


Token 


6.3.20 












Table 1.31 : SubscriberAuthenticationRequest Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.319 


m 








2 


Sourcelnfo 


6.3.16 


m 








3 


SourceAlternate 


6.3.15 


m 








4 


Destinationlnfo 


6.3.9 











5 


Service 


6.3.14 
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Table 1.32: SubscriberAuthenticationResponse Support 



Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Status 


6.3.18 


m 








3 


SubscriberAuthenticationlnfo 


6.3.37 











Table 1.33: Capabilitieslndication Support 


Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Devicelnfo 


6.3.38 











2 


OSPVersion 


6.3.36 


m 








3 


OSPCapability 


6.3.32 











4 


Resources 


6.3.40 











5 


Data Rate 


6.3.41 











6 


NumberOfChannels 


6.3.42 











7 


Bandwidth 


6.3.43 











8 


AlmostOutOfResources 


6.3.44 











Table 1.34: CapabilitiesConf irmation Support 


Item 


Information element 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Timestamp 


6.3.19 


m 








2 


Status 


6.3.18 


m 








3 


OSPVersion 


6.3.36 


m 








4 


OSPService 


6.3.33 











5 


OSPServiceURL 


6.3.34 











6 


OSPSignatureRequired 


6.3.35 











7 


CertificateChain 


6.3.31 











8 


Certificate 


6.3.30 











9 


Deviceld 


6.3.39 












1.3. 11 Authorization Token Support 



Table 1.35: Authorization Token Support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Cryptographic Encoding 


D.1 











2 


ASN.1 format 


D.2.1 


0.1 








3 


XIVIL format 


D.2.2 


0.1 








4 


Binary XML format 


D.2.3 


0.1 









0.1: It is essential to support at least one of these formats. 

Table 1.36: Cryptographic encoding type support 



Prerequisite: 
1.29/1 














Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


signed-data 


PKCS7 











2 


encrypted-data 


PKCS7 
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Table 1.37: Authorization Tol<en Support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


DigestAlgorithm 


PKCS7 











2 


DigestEncryptionAlgorithm 


PKCS7 











Table 1.38: Authorization Token Support 


Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


md2 


X.509 


0.1 








2 


md4 


X.509 


0.1 








3 


md5 


X.509 


0.1 








4 


sha-1 


ISO 


0.1 









o. 1 : It is essential to support at least one of these formats. 

Table 1.39: Authorization Token Support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


RsaEncryption 


PKCS1 


0.1 








2 


id-dsa-with-shal 


ISO 


0.1 









o. 1 : It is essential to support at least one of these formats. 

Table 1.40: Authorization Token Support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


KeyEncryptionAlgorithm 


PKCS7 











2 


ContentEncryptionAlgorithm 


PKCS7 












Table 1.41 : Authorization Token Support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


rsaEncryption 


PKCS1 












Table 1.42: Authorization Token Support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


des-ede3-cbc 


ISO 


0.1 








2 


rc2-cbc 


ISO 


0.1 









0.1: It is essential to support at least one of these formats. 
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Table 1.43: ASN.1 format token support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Random 


D.2.1 


m 








2 


Sourcelnfo 


D.2.1 


m 








3 


Destinationlnfo 


D.2.1 


m 








4 


Callld 


D.2.1 











5 


ValidAfter 


D.2.1 











6 


ValidUntil 


D.2.1 











7 


Transaction Id 


D.2.1 











8 


ServiceAuthorized 


D.2.1 











9 


AuthorityURL 


D.2.1 












Table 1.44: ASN.1 format source info and destination info coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Maximum instances 


D.2.1 


m 




0.. 




2 


el 64 


H.225.0 [9] 


0.1 








3 


h323-ID 


H.225.0 [9] 


0.1 








4 


urI-ID 


H.225.0 [9] 


0.1 








5 


transport-ID 


H.225.0 [9] 


0.1 








6 


email-ID 


H.225.0 [9] 


0.1 








7 


PartyNumber 


H.225.0 [9] 


0.1 









0.1: It is essential to support at least one of these formats. 



Table 1.45: ASN.1 format transport-id coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


IpAddress 


H.225.0 [9] 


0.1 








2 


IpSourceRoute 


H.225.0 [9] 


0.1 








3 


Ipxaddress 


H 225.0 [9] 


0.1 








4 


ip6Address 


H.225.0 [91 


0.1 








5 


NetBIOS 


H.225.0 [9] 


0.1 








6 


Nsap 


H.225.0 [91 


0.1 








7 


NonStandardAddress 


H.225.0 [9] 


0.1 









0.1: It is essential to support at least one of these formats. 

Table 1.46: ASN.1 format ServiceAuthorized coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Maximum instances 


D.2.1 


m 




0.. 




2 


Service 


D.2.1 


m 








3 


Limit 


D.2.1 












Table 1.47: ASN.1 format service coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


BasicTelephony 


D.2.1 











2 


VendorSpecific 


D.2.1 
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Table 1.48: ASN.1 format limit coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Amount 


D.2.1 


m 








2 


Units 


D.2.1 


m 








3 


Increment 


D.2.1 


m 








4 


VendorSpecific 


D.2.1 












Table 1.49: ASN.1 format unit coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Seconds 


D.2.1 


0.1 








2 


Packets 


D.2.1 


0.1 








3 


Bytes 


D.2.1 


0.1 








4 


VendorSpecific 


D.2.1 


0.1 









0.1: It is essential to support at least one of these formats. 



Table 1.50: XIVIL format token support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Sourcelnfo 


6.3.16 











2 


SourceAlternate 


6.3.15 











3 


Destinationlnfo 


6.3.9 











4 


DestinationAlternate 


6.3.8 











5 


Callld 


6.3.3 











6 


ValidAfter 


6.3.24 











7 


ValidUntil 


6.3.25 











8 


Transaction Id 


6.3.21 











9 


UsageDetail 


6.3.23 











10 


AuthorityURL 


6.3.2 











11 


SourceSignalAddress 


6.3.17 











12 


DestinationSignalAddress 


6.3.10 












Table 1.51 : XML format source or destination token coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


el 64 


6.3.9 


0.1 








2 


h323 


6.3.9 


0.1 








3 


uri 


6.3.9 


0.1 








4 


Email 


6.3.9 


0.1 








5 


Transport 


6.3.9 


0.1 








6 


International 


6.3.9 


0.1 








7 


National 


6.3.9 


0.1 








8 


Network 


6.3.9 


0.1 








9 


Subscriber 


6.3.9 


0.1 








10 


Abbreviated 


6.3.9 


0.1 








11 


e164prefix 


6.3.9 


0.1 








12 


iso7812 


6.3.15 


0.1 








13 


pin 


6.3.15 


0.1 








14 


epin 


6.3.15 


0.1 








15 


devicelD 


6.3.15 


0.1 









0.1: It is essential to support at least one of these formats. 
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Table 1.52: XML source alternate or destination alternate coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Maximum instances 


D.2.2 


m 








2 


el 64 


6.3.9 


0.1 








3 


h323 


6.3.9 


0.1 








4 


uri 


6.3.9 


0.1 








5 


Email 


6.3.9 


0.1 








6 


Transport 


6.3.9 


0.1 








7 


International 


6.3.9 


0.1 








8 


National 


6.3.9 


0.1 








9 


Network 


6.3.9 


0.1 








10 


Subscriber 


6.3.9 


0.1 








11 


Abbreviated 


6.3.9 


0.1 








12 


e164prefix 


6.3.9 


0.1 








13 


iso7812 


6.3.15 


0.1 








14 


pin 


6.3.15 


0.1 








15 


epin 


6.3.15 


0.1 








16 


devicelD 


6.3.15 


0.1 









0.1; It is essential to support at least one of these formats. 

Table 1.53: XIUIL call id coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


IVIaximum instances 


D.2.2 


m 




0.. 




2 


CDATA encoding 


6.3.3 


0.1 








3 


base64 encoding 


6.3.3 


0.1 









0.1: It is essential to support at least one of these formats. 



Table 1.54: XIVIL UsageDetail coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


Maximum instances 


D.2.2 


m 




0.. 




2 


Service 


6.3.14 


m 








3 


Amount 


6.3.1 


m 








4 


Increment 


6.3.11 


m 








5 


Unit 


6.3.22 


m 








6 


StartTime 


6.3.27 











7 


EndTime 


6.3.26 











8 


TerminationCause 


6.3.29 











9 


TCCode 


6.3.28 











10 


Description 


6.3.6 











11 


Statistics 


C.1.1 












Table 1.55: XML units coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


s 


6.3.22 


0.1 








2 


pkt 


6.3.22 


0.1 








3 


byte 


6.3.22 


0.1 









0.1: It is essential to support at least one of these formats. 
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Table 1.56: XML Statistics coding support 



Item 


Capability 


Reference 


Status 


Support 
Y 1 N 1 n/a 


Values 
allowed 


Values 
supported 


1 


LossSent 


C.1.2 











2 


LossReceived 


C.1.5 











3 


Packets 


C.1.3 











4 


Fraction 


C.1.4 











5 


OneWayDelay 


C.1.6 











6 


Minimum 


C.1.7 











7 


IVIean 


C.1.8 











8 


Variance 


C.1.9 











9 


Samples 


C.I. 10 











10 


RoundTripDelay 


C.I. 11 











11 


IVIinimum 


C.1.7 











12 


IVIean 


C.1.8 











13 


Variance 


C.1.9 











14 


Samples 


C.1.10 












1.3.12 XML Extensions 



List XML extensions generated by implementation (optional): 



List XML extensions recognized by implementation (optional): 
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Annex J (informative): 

OSP Applications and Implementations 

This annex describes the application of ETSI TS 101 321, the Open Settlement Protocol, in various network 
implementations. 



J.1 Call Control Protocols 



The Open Settlement Protocol (OSP) is not limited to any particular call control protocol. Rather, it is neutral, and is 
designed for deployment with devices conforming to H.323 [13] and Session Initiation Protocol (SIP), as well as 
various proprietary signalling protocols. 

NOTE: Some well-known IP telephony protocols, including the Simple Gateway Control Protocol (SGCP), IP 
Device Control (IPDC), Media Gateway Control Protocol (MGCP), and MEGACO/H.248, do not 
integrate directly with OSP. Instead, systems relying on those protocols integrate with OSP at the level of 
protocols between gateway controllers (e.g. call agents). Today, those protocols are primarily based on 
H.323 [13] or SIP. 

This section illustrates how OSP may be used with various call signalling protocols. Rather than considering each 
protocol separately, however, it considers three different architectures — peer-to-peer, distributed tightly-coupled, and 
distributed loosely-coupled — that can be applied to various signalling protocols. The H.323 [13] and SIP protocols are 
used as examples to describe the interaction with OSP in detail. The principals described in these sections can also be 
used for other protocols. 

J. 1.1 Peer-to-Peer Architecture 

In a peer-to-peer architecture, gateways contact each other directly, without any control or co-ordination from other 
devices. This architecture corresponds to simple H.323 [13] deployments without gatekeepers as well as basic SIP- 
based services. In such an environment, the endpoints of a call implement the open settlement protocol to find and 
authorize each other, and to directly report usage information to a settlement provider. The following subsections 
illustrate the use of OSP and in both H.323 [13] and SIP architectures. 



J. 1.1.1 H.323 Gateways 



When operating with H.323 [13] gateways, OSP provides services at both the start and end of each call. During initial 
call setup, gateways can use OSP to obtain call routing information and authorization tokens. Once the call has ended, 
gateways use OSP to report usage details. 
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J.1 .1 .1 .1 Call Routing and Authorization 

The following figure shows how the open settlement protocol may be used by H.323 [13] gateways to find and 
authorize each other. 



Telephone 




<AuthReq> 



Figure J.I 

The figure highlights the following interactions between the devices. 

Calling party indicates the desired, destination phone number to Gateway A (by, for example, responding to a DTMF- 
based IVR, sending an ISDN Q.931 Setup, or transmitting an SS7 Initial Address Message). 

Gateway A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements within 
the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<Service/> 

<MaximumDestinations> 



Time of request 

H.323 [13] Call Identifier to be used for the call 

Calling party's E.164 [12] number if available; otherwise a local E.164 [12] number 
controlled by Gateway A, e.g. 14048724887; this number 
shall be passed to the destination gateway(s) in Setup messages 

DNS name or IP address of Gateway A, for example gatewayA . carrier . com 



Called party's E.164 [12] number, e.g. 33492944299 



Empty (for basic service) 

The maximum number of destinations, including alternatives. Gateway A will 
consider 



OSP Server replies with an <AuthorizationResponse> message. The message indicates two candidate 
destinations: Gateway B and Gateway C, in that order. In particular, the <AuthorizationResponse> contains the 
following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 
transaction identifier assigned by settlement provider 
first destination gateway to try for call 
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DNS name or IP address of Gateway B, for example gatewayB. itsp.fr 



<Destination 
SignalAddres 



type="transp 
ort"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
<Destination> 



<Destination 
SignalAddres 
s 

type="transp 
ort"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gateway B 

time after wliich token for Gateway B is valid 

time until which token for Gateway B is valid 

how much service is authorized with Gateway B 

empty (for basic service) 

amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

H.323 [13] Call Identifier to be used for the call to Gateway B 

second destination gateway to try for call 

DNS name or IP address of Gateway C, for example gatewayC .isp.fr 



authorization token to be passed to Gateway C 

time after which token for Gateway C is valid 

time until which token for Gateway C is valid 

how much service is authorized with Gateway C 

empty (for basic service) 

amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

H.323 [13] Call Identifier to be used for the call to Gateway C 



Gateway A sends an H.225.0 [9] Setup message to Gateway B; however, the Setup is refused with a Release Complete. 

NOTE: The H.323 [13] Call Identifier in the Setup message has the same value as in the original 

<AuthorizationRequest>. The Setup shall also include the authorization token(s) provided in the 
OSP <AuthorizationResponse>. For maximum interoperability, any tokens should use the 
following object identifier, constructed according to ETSI guidelines. 

itu-t(O), identified-organization(4), etsi(O), ts- 101-32 1(1321), token(l), xml-format(2) 

Gateway A then sends a second H.225.0 [9] Setup message, this time to Gateway C, and this time the Setup is accepted 
with a Setup Acknowledge. This Setup message also uses the H.323 [13] Call Identifier from the 
<AuthorizationRequest>, and the Setup message shall also include the authorization token(s) provided in the 
OSP <AuthorizationResponse>. For maximum interoperability, any tokens should use the following object 
identifier, constructed according to ETSI guidelines. 

itu-t(O), identified-organization(4), etsi(O), ts- 101-32 1(1321), token(l), xml-format(2) 

Gateway C accepts the Setup and completes the call to the called party; the phone conversation can now take place. 
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J.1 .1 .1 .2 Usage Reports 

Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those 
reports are conveyed in OSP <UsageIndication> messages. 

Telephone 



Release Complete 

e 





OSP 
Server 



H.323 Gateway C 

o 

<Usagelnd> 



Figure J.2 

The steps shown in the figure are straightforward. 

Gateways A and C clear the call by exchanging an H. 225.0 [9] Release Complete message. 

Gateway A sends a <UsageIndication> message to the OSP server. If Gateway A is not using any protocol 
extensions, the message will contain the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 

type="transpo 
rt"> 



time of request 

for Gateway A, source 

tran.saction ID assigned by OSP server in authorization response 

H.323 [13] Call Identifier used for the call 

calling party's E. 164 [12] number as returned in the authorization response, e.g. 

14048724887 

DNS name or IP address of Gateway A, for example gatewayA . carrier . com 



called party's E. 164 [12] number, e.g. 33492944299 

DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
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Gateway C also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type=" transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceived> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gateway C, destination 

transaction ID assigned by OSP server and passed to Gateway C in 
authorization token 

H.323 [13] Call Identifier used for the call 

calling party's E.164 [12] number as presented in the Setup message, e.g. 

14048724887 

DNS name or IP address of Gateway A, for example [172.16.1.1] 

called party's E.164 [12] number, e.g. 334 92 944299 

DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway C 

number of packets lost from Gateway C to Gateway A 

fraction (from to 255) of packets lost from C to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway C 

fraction (from to 255) of packets lost from A to C 

one way delay measured from Gateway A to C 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Gateway A and C measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

J.1 .1 .2 Session Initiation Protocol Gateways 

In a simple peer-to-peer environment, Session Initiation Protocol (SIP) gateways operate in a manner nearly identical to 
H.323 [13] gateways. As before, it is convenient to consider interaction using OSP before and after the multimedia call. 
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J.1 .1 .2.1 Call Routing and Authorization 

The following figure shows how the open settlement protocol may be used by SIP gateways to find and authorize each 
other. 

NOTE 1 : This function allows a SIP gateway to find a peer gateway for a particular, PSTN-terminated, telephone 
user. As such, it is not the same as the standard SIP user location function. 




Telephone 



OSP 
Server 



SIP Gateway B 



©ring |^ 
phone %^ 



phone 
INVITE/ 200 /ACK 




SIP Gateway 



Figure J.3 

The figure highlights the following interactions between the devices. 

Calling party indicates the desired, destination phone number to Gateway A (by, for example, responding to a DTMF- 
based IVR, sending an ISDN Q.931 Setup, or transmitting an SS7 Initial Address Message). 

Gateway A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements within 
the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<Service/> 

<MaximumDestinations> 



time of request 

SIP Call-ID to be used for the call 

calling party's E. 164 [12] number if available; otherwise a local E. 164 [12] number 
controlled by Gateway A, e.g. 14048724887; this number 
shall be passed to the destination gateway(s) in the subsequent 
INVITE method 

DNS name or IP address of Gateway A, for example gatewayA . car r ie r . com 



called party's E. 164 [12] number, e.g. 33492944299 

empty (for basic service) 

the maximum number of destinations, including alternatives. Gateway A will consider 
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OSP Server replies with an <AuthorizationResponse> message. The message indicates two candidate 
destinations: Gateway B and Gateway C, in that order. In particular, the <AuthorizationResponse> contains the 
following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gateway B, for example gatewayB. itsp.fr 



<Destination 
SignalAddres 
s 

type="transp 
ort"> 



<Token> 

<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
<Destination> 



authorization token to be passed to Gateway B 

time after which token for Gateway B is valid 

time until which token for Gateway B is valid 

how much service is authorized with Gateway B 

empty (for basic service) 

amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

SIP Call-ID to be used for the call to Gateway B 

second destination gateway to try for call 

DNS name or IP address of Gateway C, for example gatewayC .isp.fr 



<Destination 
SignalAddres 

3 

type="transp 
ort"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gateway C 
time after which token for Gateway C is valid 
time until which token for Gateway C is valid 
how much service is authorized with Gateway C 
empty (for basic service) 
amount of authorized service, e.g. 3 60 
increment of service measurement, e.g. 1 
unit of service measurement, e.g. s for seconds 
SIP Call- ID to be used for the call to Gateway C 

Gateway A sends an INVITE message to Gateway B; however, Gateway B cannot accept the request. It responds with a 
"503 Service Unavailable," which Gateway A acknowledges with an ACK. 

NOTE 2: The SIP Call-ID in the INVITE message has the same value as in the original 

<AuthorizationRequest>. The INVITE shall also include authorization token(s) provided in the 
OSP <AuthorizationResponse>. Each token should be conveyed in the SIP message body using 
the application/osp-token MIME type, as initially defined in draft-thomas-mime-osp-token-OO.txt. 

Gateway A then sends a second INVITE message, this time to Gateway C, and this time the INVITE is accepted with 
"200 Success," to which Gateway A replies with an ACK. This INVITE message also uses the SIP Call-ID from the 
<AuthorizationRequest>, and the INVITE shall also include the authorization token(s) provided in the OSP 
<AuthorizationResponse>. Each token should be conveyed in the SIP message body using the application/osp- 
token MIME type, as initially defined in draft-thomas-mime-osp-token-OO.txt. 

Gateway C accepts the INVITE and completes the call to the called party; the phone conversation can now take place. 
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J. 1.1. 2.2 Usage Reports 

Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those 
reports are conveyed in OSP <UsageIndication> messages. 
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Figure J.4 

The steps shown in the figure are straightforward. 

Gateways A and C clear the call with a SIP BYE message. 

Gateway A sends a <UsageIndication> message to the OSP server. If Gateway A is not using any protocol 
extensions, the message will contain the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 

type="transpo 
rt"> 



<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



time of request 

for Gateway A, source 

tran.saction ID assigned by OSP server in authorization response 

SIP Call- ID used for the call 

calling party's E.164 [12] number as returned in the authorization response, e.g. 

14048724887 

DNS name or IP address of Gateway A, for example gatewayA . carrier . com 



called party's E.164 [12] number, e.g. 33492944299 

DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 
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The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

Gateway C also sends a <UsageIndication> to the OSP server. 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type=" transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceived> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gateway C, destination 

transaction ID assigned by OSP server and passed to Gateway C in 
authorization token 

SIP Call-ID used for the call 

calling party's E.I64 [12] number as presented in the INVITE inessage, e.g. 

14048724887 

DNS name or IP address of Gateway A, for example [172.16.1.1] 

called party's E.I 64 [12] number, e.g. 334 92 944299 

DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway C 

number of packets lost from Gateway C to Gateway A 

fraction (from to 255) of packets lost from C to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway C 

fraction (from to 255) of packets lost from A to C 

one way delay measured from Gateway A to C 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Gateway A and C measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irination> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



J.1 .2 Tightly Controlled Distributed Architecture 

The Open Settlement Protocol supports operation in a tightly controlled, distributed architecture. That architecture 
includes some H.323 [13]-based deployments with active gatekeepers and SIP proxy servers (but not SIP redirect 
servers). The following subsections illustrate the use of OSP in those environments. 
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J. 1.2.1 H.323 Gatekeeper Routed Calls 



In H.323 [13] deployments with gatekeepers, the gatekeeper may play a very active roll in call signalling. In such an 
environment, gatekeepers not only assume responsibility for call routing and authorization on behalf of their endpoints. 
They also act as the signalling endpoint for calls into their zone. As the following figure shows, gatekeepers may 
support multimedia terminals as well as gateways. As that figure and the following figure also highlight, only 
gatekeepers are required to support the Open Settlement Protocol in this environment. 



H.323 Terminal 



Telephone 




<AuthReq> 



Figure J.5 

NOTE: All destination gateways (or endpoints) controlled by the gatekeepers shall be equivalent, as far as the 
OSP server is concerned. Indeed, the OS? server is not even aware of the existence of any H.323 [13] 
terminals or gateways. Such an architecture, therefore, places implicit restrictions on the services offered 
by the operators. An operator, for example, will be unable to price termination services differently for 
different gateways in the same zone. 

J.I .2.1 .1 Call Routing and Authorization 

H.323 [13] Terminal begins a call by sending an H. 225.0 [9] Setup message its gatekeeper. Gatekeeper A. 

NOTE: This scenario assumes the use of pre-granted admission requests. 

The Setup indicates that the called party is identified by an E.164 [12] phone number such as +33 4 92 94 42 99. 

Gatekeeper A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements 
within the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 



type="transpo 
rt"> 



<DestinationInfo 



time of request 

H.323 [13] Call Identifier to be used for the call 

a representation of the H.323 [13] Terminal using an E.164 [12] number; in the 
absence of other information, this number may be derived 
using the IP address to E.164 [12] number mapping of ETSI 
TIPHON; this number shall be passed to the destination 
gateway(s) in Setup messages 

DNS name or IP address of Gatekeeper A, for example 

gatekeeperA. carrier . com 



called party's E.164 [12] number, e.g. 33492944299 
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type="el64"> 
<Service/> 
<MaximumDestinations> 



empty (for basic service) 

the maximum number of destinations, including alternatives. Gatekeeper A will 
consider 



OSP Server replies with an <AuthorizationResponse> message. The message identifies Gatekeeper B. In 
particular, the <AuthorizationResponse> contains the following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gatekeeper B, for example gatekeeperB. ltsp.fr 



<Destination 
SignalAddres 



type="transp 
ort"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gatekeeper B 

time after which token for Gatekeeper B is valid 

time until which token for Gatekeeper B is valid 

how much service is authorized with Gatekeeper B 

empty (for basic service) 

amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

H.323 [13] Call Identifier to be used for the call to Gatekeeper B 



Gatekeeper A extends the call with its own Setup message to Gatekeeper B. 

Gatekeeper B accepts the Setup and extends the call to the destination gateway with another Setup/Setup Acknowledge 
exchange. 

The Gateway adds the final leg of the call by dialling the called party; the phone conversation can now take place. 
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J. 1.2.1. 2 Usage Reports 

At the conclusion of the phone call, both gatekeepers shall report usage information to the OSP server. The following 
figure identifies the principle steps of a typical call completion. 
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Figure J.6 

The steps shown in the figure are straightforward. 

The gatekeepers release the call with an exchange of H. 225.0 [9] Release and Release Complete messages. 

Gatekeeper A then sends a <UsageIndication> message to the OSP server. In this example Gatekeeper A may not 
be able to support protocol extensions such as statistics. Its message, therefore contains just the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 

type="transpo 
rt"> 



time of request 

for Gatekeeper A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [13] Call Identifier used for the call 

calling party's E. 164 [12] number as returned in the authorization response, e.g. 

14048724887 

DNS name or IP address of Gatekeeper A, for example 

gatekeeperA. carrier . com 



called party's E. 164 [12] number, e.g. 33492944299 

DNS name or IP address of Gatekeeper B, for example, gatekeeperB . itsp . f r 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
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Gatekeeper B also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type=" transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceived> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gatekeeper B, destination 

transaction ID assigned by OSP server and passed to Gatekeeper B in 
authorization token 

H.323 [13] Call Identifier used for the call 

calling party's E.164 [12] number as presented in the Setup message, e.g. 

14048724887 

DNS name or IP address of H.323 [13] Terminal, for example 

[172.16.100.1] 

called party's E.164 [12] number, e.g. 334 92 944299 

DNS name or IP address of Gatekeeper B, for example, 

gatekeeperB . itsp . f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

Increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gatekeeper B 

number of packets lost from Gatekeeper B to H.323 [13] Terminal 

fraction (from to 255) of packets lost from B to H.323 [13] Terminal 

loss information for packets sent by H.323 [13] Terminal 

number of packets lost from H.323 [13] Terminal to Gatekeeper B 

fraction (from to 255) of packets lost from Terminal to B 

one way delay measured from Terminal to B 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Terminal and B measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



J.1 .2.2 Session Initiation Protocol Proxy Servers 

Session Initiation Protocol (SIP) proxy servers may function in a manner similar to H.323 [13] gatekeepers. In such an 
environment, the proxy servers may support the Open Settlement Protocol, while the systems on whose behalf they act 
need not. 

NOTE: All destination gateways (or endpoints) served by the SIP proxies shall be equivalent, as far as the OSP 
server is concerned. Indeed, the OSP server is not even aware of the existence of any endpoints or 
gateways. Such an architecture, therefore, places implicit restrictions on the services offered by the 
operators. An operator, for example, will be unable to price termination services differently for different 
gateways served by the same proxy. 



ETSI 



96 



ETSI TS 101 321 V2.1.1 (2000-08) 



J. 1.2.2.1 Call Routing and Authorization 

The following figure shows how OSP plays a role in environments that use SIP Proxy Servers. In the figure. The SIP 
Proxy Server, acting on behalf of the SIP client, completes a call to a SIP Gateway, and ultimately to the PSTN. 



SIP Client 



Telephone 




Figure J.7 

The SIP Client begins a call by sending an INVITE request to its proxy server. The INVITE indicates that the called 
party is identified by an E. 164 [12] phone number such as +33 4 92 94 42 99. 

The SIP Proxy Server sends an OSP <AuthorizationRequest> message to the OSP Server. The significant 
elements within the <AuthorizationRequest> include the following: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el64"> 

<Service/> 

<MaximumDestinations> 



time of request 

SIP Call-ID to be used for the call 

a representation of the SIP client using an E. 164 [12] number; in the absence of 
other information, this number may be derived using the IP 
address to E.164 [12] number mapping of ETSI TIPHON. 

DNS name or IP address of the Proxy Server, for example proxy . carrier . com 



called party's E.164 [12] number, e.g. 33492944299 



empty (for basic service) 

the maximum number of destinations, including alternatives, the Proxy Server will 
consider 
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OSP Server replies with an <AuthorizationResponse> message. The message identifies the SIP gateway. In 
particular, the <AuthorizationResponse> contains the following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 

<DestinationSignalAddress 

type="transpor 
t"> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of destination gateway, e.g. gateway . itsp . f r 



authorization token to be passed to Gateway 

time after which token for Gateway is valid 

time until which token for Gateway is valid 

how much service is authorized with Gateway 

empty (for basic service) 

amount of authorized service, e.g. 3600 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

SIP Call-ID to be used for the call to the Gateway 

The Proxy Server, acting on behalf of its client, sends an SIP INVITE to the Gateway. In this example, the Gateway 
accepts the connection with an 200, and the proxy responds with an ACK. This INVITE message also uses the SIP Call- 
ID from the <AuthorizationRequest>, and the INVITE shall also include the authorization token(s) provided in 
the OSP <AuthorizationResponse>. Each token should be conveyed in the SIP message body using the 
application/osp-token MIME type, as initially defined in draft-thomas-mime-osp-token-OO.txt. 

The Proxy Server, on establishing the connection with the Gateway, completes the connection with its client as well 
with a SIP 200/ ACK exchange. 

The Gateway, meanwhile, completes the call to the destination phone number. 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
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J. 1.2.2.2 Usage Reports 

At the conclusion of the phone call, both the Proxy Server and Gateway report usage information to the OSP server. 
The following figure identifies the principle steps of a typical call completion. 
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Figure J.8 

The steps shown in the figure are straightforward. 

The Proxy Server and Gateway release the call by transferring a SIP BYE message. 

The Proxy Server then sends a <UsageIndication> message to the OSP server. In this example, the Proxy Server 
does not support new protocol extensions such as statistics. Its message, therefore contains just the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 

type="transpo 
rt"> 



time of request 

for Proxy Server, source 

transaction ID assigned by OSP server in authorization response 

SIP Call-ID used for the call 

calling party's E.164 [12] number as returned in the authorization response, e.g. 

14048724887 

DNS name or IP address of the Proxy Server, for example proxy . carrier . com 



called party's E.164 [12] number, e.g. 33492944299 

DNS name or IP address of the Gateway, for example, gateway . itsp . f r 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
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The Gateway also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type=" transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceived> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for the Gateway, destination 

transaction ID assigned by OSP server and passed to the gateway in 
authorization token 

SIP Call-ID used for the call 

calling party's E.164 [12] number as presented in the INVITE message, e.g. 

14048724887 

DNS name or IP address of the Proxy Server, for example 

[172.16.100.1] 

called party's E.164 [12] number, e.g. 334 92 944299 

DNS name or IP address of the Gateway, for example, gateway, itsp.fr 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

Increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by the Gateway 

number of packets lost from the Gateway to the Proxy Server 

fraction (from to 255) of packets lost from the Gateway to the Proxy Server 

loss information for packets sent by the Proxy Server 

number of packets lost from Proxy Server to the Gateway 

fraction (from to 255) of packets lost from Proxy Server to Gateway 

one way delay measured from Proxy Server to Gateway 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Proxy Server and Gateway measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 



The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

J.1 .3 Loosely Controlled Distributed Architecture 

The Open Settlement Protocol can also be used in environments based on loosely-coupled, distributed architectures. 
One such environment is an H.323 [13]-based architecture with direct call signalling. Another example is the use 
Session Initiation Protocol (SIP) redirect servers. This subsection describes the use of OSP in each of these 
architectures. 
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J. 1.3.1 H.323 Direct Routed Calls (with Gatekeepers) 

When H.323 [13] gateways and gatekeepers both implement the Open Settlement Protocol, it is possible to use OSP in 
an architecture that relies on H.323 [13] Direct Call Signalling (as opposed to Gatekeeper Call Signalling). Such an 
approach is a hybrid of the peer-to-peer gateway architecture and the tightly controlled gatekeeper model discussed in 
the previous two subsections. In this approach, the gatekeepers acts as agents for call routing and authorization, but the 
gateways themselves are responsible for establishing and disconnecting calls directly with each other. In addition to 
gateways, H.323 [13] proxy devices may also be used to support this model on behalf of H.323 [13] terminals. 

J.1 .3.1 .1 Call Routing and Authorization 

The following figure shows a sample routing and authorization scenario for this model. 

NOTE 1 : This figure shows a finer level of detail than previous examples in order to clarify several subtle points. 
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Figure J.9 

Gateway A begins a call by sending an H. 225.0 [9] Admission Request (ARQ) to its gatekeeper. Gatekeeper A. The 
ARQ indicates that the called party is identified by an E.164 [12] phone number such as H-33 4 92 94 42 99. 

Gatekeeper A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements 
within the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 



time of request 

H.323 [13] Call Identifier to be used for the call 

the called party's E.164 [12] number, or, if that is not available, a local E.164 [12] 

number belonging to Gateway A; this number shall be passed 
to the destination gateway(s) in Setup messages 

DNS name or IP address of Gatekeeper A, for example 

gatekeeperA. carrier . com 
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rt"> 

<SourceAlternate 

type="h323"> 

<DestinationInfo 

type="el64"> 

<Service/> 

<MaximumDestinations> 



H.323 [13] identifier of Gateway A, e.g. 12345678 
called party's E.164 [12] number, e.g. 33492944299 

empty (for basic service) 

the maximum number of destinations, including alternatives. Gatekeeper A will 
consider 



OSP Server replies with an <AuthorizationResponse> message. The message identifies Gateway B and 
Gateway C as candidate destinations. In particular, the <AuthorizationResponse> contains the following 
elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 

<DestinationSignalAddress 

type=" transport 
"> 

<Token> 

<ValidAfter> 

<ValidUntil> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 
<CallId> 
<Destination> 

<DestinationSignalAddress 

type=" transport 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gateway B, for example gateways . itsp . f r 



authorization token to be passed to Gateway B 

time after which token for Gateway B is valid 

time until which token for Gateway B is valid 

how much service is authorized with Gateway B 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

H.323 [13] Call Identifier to be used for the call to Gateway B 

second destination gateway to try for call 

DNS name or IP address of destination Gateway C, e.g. gatewayC .isp.fr 



authorization token to be passed to Gateway C 

time after which token for Gateway C is valid 

time until which token for Gateway C is valid 

how much service is authorized with Gateway C 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

H.323 [13] Call Identifier to be used for the call to Gateway C 

Gatekeeper A sends an H. 225.0 [9] Admission Confirm (ACF) message to its gateway. That ACF identifies the 
destination as Gateway B and it shall include the authorization token for gateway B. 

Gateway A sends an H.225.0 [9] Setup message to Gateway B. This Setup message uses the H.323 [13] Call Identifier 
from the <AuthorizationRequest>, and the message shall include the authorization token(s) provided in the OSP 

<AuthorizationResponse>. 

Gateway B refuses the setup attempt with a Release Complete message, perhaps, for example, because no outbound 
PSTN ports are available. 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
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Gateway A sends another Admission Request (ARQ) message to its gatekeeper to request an alternate destination for 
the phone call. 

NOTE 2: This ARQ shall use the same H.323 [13] Call Identifier as the original ARQ. For clarity, the example 
omits other details of the exchange between Gateway A and Gatekeeper A, such as, for example, a 
Disengage Request (DRQ) and Disengage Confirm (DCF). 

Gatekeeper A replies with an Admission Confirm (ACF) message that identifies Gateway C as a potential destination. 

NOTE 3: The Gatekeeper need not query the OSP server to get that information. Rather, the information is 
available in the original <AuthorizationResponse> noted in step 3. 

Gateway A tries a second setup attempt, this time by sending a Setup message to Gateway C. 

Gateway C receives the Setup message and asks its gatekeeper for permission to accept the call. It does so by sending 
an Admission Request (ARQ) to Gatekeeper C. 

NOTE 4: This message shall include the authorization token(s) received in the Setup. 

Gatekeeper C authorizes the call and returns an Admission Confirm (ACF) message to Gateway C. 

Gateway C receives the ACF and accepts the call by returning a Setup Acknowledge message to Gateway A. 



J. 1.3.1.2 



Usage Reports 



At the conclusion of the phone call, both gateways shall report usage information to the OSP server. The following 
figure identifies the principle steps of a typical call completion. 




H.323 Gatekeeper C 



o 

<Usagelnd> 



OSP 
Server 



Figure J. 10 

The steps shown in the figure are straightforward. 

The gateways close the connection by exchanging H.323 [13] Release and Release Complete messages. 
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Gateway A then sends a <UsageIndication> message to the OSP server. In this example Gateway A's message 
will include two complete <UsageIndication> components, one for the failed attempt and one for the successful 
call. The sub-elements for each will include the following: 



<UsageIndication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
<SourceAlternate 

type=" transport "> 

<Destinat ion Info 

type="el64"> 

<DestinationAlternate 

type=" transport "> 
<FailureReason> 
<UsageIndication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
<SourceAlternate 

type=" transport "> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 



usage information for the failed setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [13] Call Identifier used for the call 

calHng party's E.164 [12] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 



called party's E.164 [12] number as returned in the authorization response, e.g. 

33492944299 

DNS name or IP address of Gateway B, for example, gatewayB . itsp . f r 



reason for failure of attempted setup, e.g. 4 22 

usage information for the successful setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [13] Call Identifier used for the call 

calhng party's E.164 [12] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatekeeperA. carrier . com 



called party's E.164 [12] number as returned in the authorization response, e.g. 

33492944299 

DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 



type=" transport "> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 
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Gateway C also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type=" transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceived> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gateway C, destination 

Transaction ID assigned by OSP server and passed to Gateway C in 
autliorization token 

H.323 [13] Call Identifier used for the call 

calling party's E.164 [12] number as presented in the Setup message, e.g. 

14048724887 

DNS name or IP address of Gateway A, for example [172.16.100.1] 

called party's E.164 [12] number, e.g. 334 92 944299 

DNS name or IP address of Gateway C, for example, gatewayC . itsp. f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

Increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway C 

number of packets lost from Gateway C to Gateway A 

fraction (from to 255) of packets lost from C to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway C 

fraction (from to 255) of packets lost from A to C 

one way delay measured from A to C 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between A and C measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



J. 1.3. 2 Session Initiation Protocol Redirect Servers 

Session Initiation Protocol (SIP) redirect servers represent another example of the loosely coupled distributed 
architecture, particularly on the source side of a call. In this environment, the redirect server provides the call routing 
and authorization on behalf of the systems it serves, but those systems themselves report usage information. 
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J. 1.3. 2.1 Call Routing and Authorization 

The following figure shows a sample routing and authorization scenario for SIP redirect servers. 



SIP Gateway B 




SIP Gateway G 


^ 





<AuthReq> 



OSP 

Server 



Figure J. 11 

Gateway A begins a call by sending a SIP INVITE method to its redirect server. The INVITE indicates that the called 
party is identified by an E. 164 [12] phone number such as +33 4 92 94 42 99. 

The Redirect Server sends an OSP <AuthorizationRequest> message to the OSP Server. The significant 
elements within the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="elf 



<SourceAlternate 

type="transpo 
rt"> 

<SourceAlternate 

type="h323"> 



<DestinationInf o 

type="el64"> 

<Service/> 

<MaximumDestinations> 



time of request 

SIP Call-ID to be used for the call 

calling party's E.164 [12] number if available; otherwise a local E.164 [12] number 
controlled by Gateway A (e.g. 1 4 4 8 7 2 4 8 8 7); this number 
shall be passed to the destination gateway(s) in future INVITE 
messages 

DNS name or IP address of Redirect Server, for example 

redirect . carrier . com 



DNS name or IP address of Gateway A, for example gatewayA . carrier . com; 
the type " h 3 2 3 " , in this case, implies a device-specific ID 
rather than a particular protocol 

called party's E.164 [12] number, e.g. 33492944299 



empty (for basic service) 

the maximum number of destinations, including alternatives. Redirect Server will 
consider 
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OSP Server replies with an <AuthorizationResponse> message. The message identifies Gateway B and 
Gateway C as candidate destinations. In particular, the <AuthorizationResponse> contains the following 
elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gateway B, for example gatewayB. itsp.fr 



<Destination 
SignalAddres 
s 

type="transp 
ort"> 



<Token> 

<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
<Destination> 



authorization token to be passed to Gateway B 

time after which token for Gateway B is valid 

time until which token for Gateway B is valid 

how much service is authorized with Gateway B 

empty (for basic service) 

amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

SIP Call-ID to be used for the call to Gateway B 

second destination gateway to try for call 

DNS name or IP address of Gateway C, for example gatewayC .isp.fr 



<Destination 
SignalAddres 

3 

type="transp 
ort"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gateway C 
time after which token for Gateway C is valid 
time until which token for Gateway C is valid 
how much service is authorized with Gateway C 
empty (for basic service) 
amount of authorized service, e.g. 3 60 
increment of service measurement, e.g. 1 
unit of service measurement, e.g. s for seconds 
SIP Call- ID to be used for the call to Gateway C 

The Redirect Server returns a "300 Multiple Choices" redirection status code to Gateway A. This response relays the 
data from the <AuthorizationResponse> to the gateway, explicitly identifying Gateways B and C as candidate 
destinations. This response shall also include the authorization tokens returned by the OSP Server as application/osp- 
token MIME types in the response body. 

Gateway A sends an INVITE message to Gateway B. This INVITE message uses the SIP Call-ID from the 
<AuthorizationRequest>, and the message shall include all authorization tokens associated with that destination 
in the server's OSP <AuthorizationResponse>. 

Gateway B refuses the setup attempt with a 503 message, perhaps, for example, because no outbound PSTN ports are 
available. 

Gateway A tries a second setup attempt, this time by sending an INVITE message to Gateway C. 
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Gateway C receives the INVITE message and accepts the call by responding with a 200 message, to which Gateway A 
replies with an ACK. 



J. 1.3.2.2 Usage Reports 

Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those 
reports are conveyed in OSP <UsageIndication> messages. 
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Figure J. 12 

The steps shown in the figure are straightforward. 
Gateways A and C clear the call with a SIP BYE message. 
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Gateway A sends a <UsageIndication> message to the OSP server. In this example Gateway A's message will include 
two complete <UsageIndication> components, one for the failed attempt and one for the successful call. The sub- 
elements for each will include the following: 



<UsageIndication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
<SourceAlternate 

type=" transport "> 

<Destinat ion Info 

type="el64"> 

<DestinationAlternate 

type=" transport "> 
<FailureReason> 
<UsageIndication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
<SourceAlternate 

type=" transport "> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 



usage information for the failed setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

SIP Call- ID used for the call 

caningparty'sE.164 [12] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 



called party's E. 164 [12] number as returned in the authorization response, e.g. 

33492944299 

DNS name or IP address of Gateway B, for example, gatewayB . itsp . f r 



reason for failure of attempted setup, e.g. 4 22 

usage information for the successful setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [13] Call Identifier used for the call 

caUing party's E.164 [12] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 



called party's E.164 [12] number as returned in the authorization response, e.g. 

33492944299 

DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 



type=" transport "> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. 1 

Unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

Gateway C also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type=" transport "> 

<DestinationInf o type="el64"> 



time of request 

For Gateway C, destination 

transaction ID assigned by OSP server and passed to Gateway C in 
authorization token 

SIP Call-ID used for the call 

calling party's E.164 [12] number as presented in the INVITE message, e.g. 

14048724887 

DNS name or IP address of Gateway A, for example [172.16.1.1] 
calledparty'sE.164 [12] number, e.g. 334 92 944299 
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<DestinationAlternate 

type=" transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceived> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



DNS name or IP address of Gateway C, for example, gatewayC .isp.fr 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway C 

number of packets lost from Gateway C to Gateway A 

fraction (from to 255) of packets lost from C to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway C 

fraction (from to 255) of packets lost from A to C 

one way delay measured from Gateway A to C 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Gateway A and C measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 
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J. 2 Prepaid Calling Card and Roaming User Support 

As the following figure shows, the most general environment requires support from four different domains: the source 
and destination domains of the IP telephony gateways, the settlement service provider, and the end user billing domain. 
User billing may distinct from the source domain in the case, for example, or a roaming user. 

The figure also shows the general operational procedure for authorization divided into seven discrete steps. 
Source Domain 




Settlement Provider 



Figure J. 13 

The user accesses a gateway in the source domain. The gateway, perhaps using an IVR application, collects the user's 
calling card number and personal identification number, in addition to the called number. 

The source gateway forwards this information to the settlement provider in an OSP <AuthorizationRequest>. 

The settlement provider, in addition to authenticating the source gateway, also authenticates the end user. That 
authentication procedure is outside the scope of OSP, but may, as the example shows, rely on another standard protocol 
such as RADIUS (RFC 2138). 

The end user billing application authenticates and authorizes the user. 

The settlement provider returns an <AuthorizationResponse> to the source gateway indicating acceptance of 
the end user and providing authorization tokens for the destination gateway. 

The call proceeds normally with a Setup message from the source to the destination gateway. 

The destination gateway completes the call to the called party. 

These steps represent the beginning of a calling card transaction. Additional phases, including refreshing the user's 
authorization and reporting usage information, can be found in the following section on implementation details. 
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J.2.1 Call Routing and Authorization 

The OSP <AuthorizationRequest> message shown in step 2 contains the following significant elements: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 



type="transpo 
rt"> 



<SourceAlternate 



type="subscri 
ber"> 



<DestinationInfo 

type="el 64 "> 

<Service/> 

<MaximumDestinations> 



Time of request 

H.323 [13] Call Identifier to be used for the call 

Calling party's E.164 [12] number if available; otherwise a local E.164 [12] number 
controlled by the source gateway, e.g. 14048724887; this 
number shall be passed to the destination gateway(s) in Setup 
messages 

DNS name or IP address of source gateway, for example 

sourcegateway . carrier . com 



The user's calling card and PIN; following conventions established by the Voice over 
IP Forum, these should be combined into a single character 
string, with the two components separated by the pound sign 
(#). For example, the calling card number 12345678, combined 
with the PIN 4444, should be represented as "12345678#4444". 

Called party's E.164 [12] number, e.g. 334 92 944299 



Empty (for basic service) 

The maximum number of destinations, including alternatives, the source gateway will 
consider 



The OSP server replies with an <AuthorizationResponse> message as the figure indicates in step 5. The 
message indicates candidate destination gateways, in order of priority. In this example (which only shows a single 
destination gateway, the OSP <AuthorizationResponse> contains the following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



<DestinationS 
ignalAddress 

type="transpo 
rt"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



time of response 

result of response, e.g. <Code>200</Code> 
transaction identifier assigned by settlement provider 
first destination gateway to try for call 

DNS name or IP address of destination gateway, for example 

destgateway . itsp . f r 



authorization token to be passed to destination gateway 

time after which token for destination gateway is valid 

time until which token for destination gateway is valid 

how much service is authorized with destination gateway 

empty (for basic service) 

amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

H.323 [13] Call Identifier to be used for the call to destination gateway 
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J.2.2 Reauthorization 

In many calling card services, it may be necessary to refresh the authorization of a call that is aheady in progress. For 
example, some debit card applications will only authorize a limited amount of service at any given time; this can 
minimize the risk of fraudulent, simultaneous use of the debit card by multiple users. In such scenarios, and when the 
users wish to continue their conversation past the limited amount of time initially authorized, it will be necessary for the 
supporting devices to request additional authorization for the call. The following figure shows the message flow for this 
process. The six steps in the figure begin when the originating gateway recognizes that the currently authorized service 
limit is approaching. 



Source Domain 




Settlement Provider 



Figure J. 14 

Source gateway recognizes that the duration currently authorized for the call is nearing its limit. 

Source gateway sends an OSP <ReauthorizationRequest> to the OSP server. 

The OSP server uses some other means (such as RADIUS, in the example) to authorize additional service for the user. 

The OSP server confirms that additional service is authorized. 

The OSP server returns a <ReauthorizationResponse> to the source gateway, granting the additional 
authorized service. The response tells the source gateway the new authorization limits explicitly, and it includes an 
updated authorization token. 

The source gateway passes the new authorization token to the destination gateway. The exact method of transfer 
depends on the gateway implementations and the particular call signalling protocol; as an example, the source gateway 
may include the token in an H.323 [13] Facility message. 
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The OSP <ReauthorizationRequest> message shown in step 9 contains the following significant elements: 



<Timestamp> 

<Role> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 



type="transpo 
rt"> 



<SourceAlternate 



type="subscri 
ber"> 



<DestinationInf o 

type="el64"> 

<DestinationAlternate 

type="transpo 
rt"> 



Time of request 

for the source gateway, source 

H.323 [13] Call Identifier used for the call 

Calling party's E.164 [12] number if available; otherwise a local E.164 [12] number 
controlled by the source gateway, e.g. 14048724887; this 
number shall be passed to the destination gateway(s) in Setup 
messages 

DNS name or IP address of source gateway, for example 

sourcegateway . carrier . com 



The user's calling card and PIN; following conventions established by the Voice 
over IP Forum, these should be combined into a single 
character string, with the two components separated by the 
pound sign (#). For example, the calling card number 
12345678, combined with the PIN 4444, should be 
represented as "12345678*4444". 

Called party's E.164 [12] number, e.g. 334 92 944299 

DNS name or IP address of destination gateway, for example, 

destgateway . itsp . f r 



transaction identifier assigned by settlement provider 

usage information for the call so far 

empty (for basic service) 

amount of service used so far, e.g. 300 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 

authorization token to be passed to destination gateway 

The OSP server returns that information within an <ReauthorizationResponse> message, as the figure 
indicates in step 12. The message refreshes the authorization information for the call. In this example, the OSP 
<AuthorizationResponse> contains the following elements: 



<TransactionId> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<Token> 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



<DestinationS 
ignalAddress 

type="transpo 
rt"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



time of response 

result of response, e.g. <Code>200</Code> 
transaction identifier assigned by settlement provider 
destination gateway to try for call 

DNS name or IP address of destination gateway, for example 

destgateway . itsp . f r 



updated authorization token to be passed to destination gateway 

time after which token for destination gateway is valid 

time until which token for destination gateway is valid 

how much (cumulative) service is authorized with destination gateway 

empty (for basic service) 

(cumulative) amount of authorized service, e.g. 3 60 

increment of service measurement, e.g. 1 

unit of service measurement, e.g. s for seconds 
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Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those 
reports are conveyed in OSP <UsageIndication> messages. 



Source Domain 



Destination Domairv 




Settlement Provider 



Figure J. 15 

The steps shown in the figure are straightforward. 

The gateways clear the call by exchanging an H. 225.0 [9] Release Complete message. 

The source gateway sends a <UsageIndication> message to the OSP server, reporting its usage details for the call. 

The OSP server acknowledges receipt with a <UsageConf irmation> message. 

The destination gateway also reports its usage details with a <UsageIndication> message. 

The server acknowledges this message as well with a <UsageConf irmation>. 

The <UsageIndication> messages from both gateways will be substantially the same. As an example, here are the 
significant fields of the source gateway's message: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

<SourceAlternate 

type="transpo 
rt"> 

<DestinationInfo 

type="el 64 "> 

<DestinationAlternate 

type="transpo 
rt"> 



time of request 

for source gateway, source 

transaction ID assigned by OSP server in authorization response 

H.323 [13] Call Identifier used for the call 

calling party's E. 164 [12] number as returned in the authorization response, e.g. 

14048724887 

DNS name or IP address of source gateway, for example 

sourcegateway . carrier . com 



called party's E. 164 [12] number, e.g. 33492944299 

DNS name or IP address of destination gateway, for example, 

destgateway . isp . f r 



<UsageDetail> 



usage information for the call 
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<Service/> empty (for basic service) 

<Amount> amount of service used, e.g. 600 

<Increment> increment of service measurement, e.g. 1 

<Unit> unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 
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